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^SC/FOX 1032 Q 1991 Silicon Composers. Inc Polo Alto. CA USA 



SC/FOX 1032 Board Features 

The 1032 is a plug-on daughter board for either 
the SBC32 stand-alone or PCS32 PC plug-in 
single board computers. 

5 MB/sec SCSI Port. 

Attach up to 7 SCSI Devices. 

4 RS232 Serial Ports, up to 230K baud. 

16-bit Bidirectional-Parallel Port, may be 

used as two 8-bit ports. 

2 programmable counter/timers. 

Prototyping area on board. 

All bus signal brought out to pads. 

Full Interrupt Support. 

Two 50-pin user application connectors. 

No jumpers, totally software configurable. 

Driver software source included. 

Single +5 Vott low-power operation. 

Full ground and power plane. 

4 Layer, Eurocard-size: 100mm x 160mm. 

User manual and interface schematics included. 

Low chip count (8 ICs) for maximum reliability. 

Test routines for SCSI, parallel, and serial 
ports supplied in source code form. 

Plug together up to 6 I032 Boards In a stack. 



Fast Data-Dispersion Program Example 
The program, SEND below, reads 1K blocks from a SCSI 
drive and transmits them out one of the I032 board's four 
RS232 serial ports at 230K Baud. SEND uses only I032 
facilities. Disk read speed is limited by SCSI drive speed. 

Program Example 



CREATE BUFR 2560 ALLOT 
:PUT(#k) 

1024 * BUFR BYTE + 

BUFR BYTE DO 

tc@ 

UEMIT 
LOOP; 
: SEND ( btock# #k) 
230KB 

BEGIN ?DUP WHILE 
2DUP 10 MIN 
>R BUFRR@SCSM) 
R@ PUT 



SWAP B> + SWAP 
REPEAT 
DROP; 



{ 10k disk buffer) 
( 1KB blocks to serial) 
( end of buffer) 
( start of buffer DO) 
( get next character) 
( and emit via serial) 
{ until done) 
{ send IK blks to serial) 
( baud rate=230KBaud!) 
( while blocks remain..) 
{ max 10K in but) 
( read nK from SCSI) 
{ and put to serial) 
{ decrement remaining) 
{ up new starting block) 
( repeat remaining test) 
( discard b»k# and exit) 



For additional product and pricing information, please contact us at: 
SIUCON COMPOSERS INC 208 Calfomia Avenue, Paio AJto, CA 94306 (415) 322-8763 
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Yerk Comes to the PC 

Rick Grehan 

In many ways, the Apple Macintosh begs for object-oriented development tools; they were 
provided by Yerkes Forth (originally marketed as Neon). The fortuitous fallout for users of the 
PC and its segmented memory architecture is this first-place entry in the FD object-oriented 
Forth contest. The author, technical director of BYTE Labs, provides an implementation that 
is complete enough to let you explore OOF to your heart's content. 

Object-Oriented Forth 

Roger Bicknell 

Object-oriented programming relies on data abstraction, information hiding, dynamic 
binding, and inheritance — and only a little work brings it to Forth. This allows one to focus on 
objects and actions, without concern about internal implementation details. The intent here is 
to reduce maintenance and increase productivity. The author, a Canadian electrical engineer, 
provides an implementation compatible with Forth-83 that incorporates the use of vocabularies. 

Simple Object-Oriented Forth 

Clive Maynard 

Forth already has the tools to create a simple object-oriented programming environment. 
This article, code, and clear examples teach the concepts involved by focusing on the use of 
defining and compiling words to create a syntax, rather than concentrating on performance. 
This educational approach is enjoyed by computer-engineering students in Australia, where the 
author is a senior lecturer. Instance variables are not discussed here and only single inheritance 
is supported; adding those and, perhaps, vectored method access, will fulfill your entrance 
requirements to the universe of object-oriented programming. 
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Objets d'Art 



Object-oriented pro- 
gramming has been 
slow to excite the col- 
lective imagination of the 
Forth community. It's hard to 
say why, because OOP and 
Forth techniques seem very 
congruous; each sheds light 
on the other and suggests 
further refinements. Maybe 
Forth programmers who look 
at OOP do so superficially, 
seeing the easy parallels but 
not the depth; or maybe we 
unconsciously remember our 
schoolteachers' prohibitions 
against passing messages in 
a class... 

This issue shows object- 
oriented Forth from several 
angles: we are pleased to 
present the winners of FDs 
object-orientedForth contest 
They are Rick Grehan, Roger 
Bicknell, andCliveMaynard. 
Their names are listed in 
order here, and our referees 
were hard pressed to deter- 
mine the final standings. 
Different and more-or-less- 
complete approaches to 
implementing OOF are rep- 
resented. There is some in- 
evitable overlap in the tuto- 
rial sections, but each article 
contains its own particular 
insights. 

How you view and use 
Forth will determine which 
of the code in this issue you 
will choose for experimenta- 
tion. Look past the surface, 
into the deeper implications 
of object-oriented Forth, and 
let us know what you find 
there. We were unable to 
publish all of the good mate- 
rial submitted to this contest, 



so we hope to present more 
in the future, along with the 
results of your own OOF 
explorations! 

Due to the amount of 
material generated by the 
above-mentioned articles, 
along with a lengthy and 
revealing excerpt from the 
on-line ANS Forth debate 
("Best of GEnie"), our usual 
"resource Listings'' have been 
postponed. A few updates 
are included, though, and 
the entire listings will reap- 
pear soon. 

Finally, welcome to the 
new year, traditionally a 
season of fresh beginnings. 
(Time to back up your data 



and reformat that hard disk.) 
FD is exploring upgrade 
options for coming issues, 
including more items about 
Forth-based solutions in ac- 
tion, Forth news, press re- 
leases and articles from 
vendors and developers, and 
a switch to wider text col- 
umns. Along with, of course, 
the fine technical fare FD 
readers expect. 

But this magazine does 
not operate in a vacuum. 
(Do I repeat myself?) New 
articles and departments 
come when someone is in- 
spired (or convinced) to write 
them. Press releases can get 
published only if businesses 
mail them. And developers' 
work gets known after they 
tell their peers about it. So 
take advantage of your citi- 
zenship in our virtual com- 
munity. You might even give 
an FD subscription (i.e., 
membership in the Forth 
Interest Group) to your boss, 
company library, or co- 
worker. As one of our letter 
writers says this month, "We 
must not do nothing." That 
would, after all, be doubly 
negative. 

— Matiin Ouverson 
Editor 
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real-world needs. Many research 
hardware and software designs that 
will advance the general state of 
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area chapter meetings are among 
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dpANS Forth Released for Public Review 

The Draft Proposed ANS Programming Language Forth 
entered its official public review period in October. Copies 
of the proposed standard may differ from development 
versions (i.e., the "BASIS" documents), and can be purchased 
from Global Engineering Documents, Inc., 2805 McGaw 
Avenue, Irvine, California 92714. Ask for document #X3-2 1 5- 
199x. From within the United States and Canada, call 800- 
854-7179; from other countries, call 714-261-1455. The U.S. 
price was to be $50 per copy; for international orders, $65 per 
copy. 

The public-review period extends from October 18, 
1991 through February 25, 1992. Please send all com- 
ments to X3 Secretariat/CBEMA, Attention: Lynn Barra, 311 
First Street N.W., Suite 500, Washington D.C. 20001-2178. 
Send a copy of your comments to American National 
Standards Institute, Attention: BSR Center, 11 West 42nd 
Street, New York, New York 10036. 

Changes from Forth-83 include removal of ambiguities 
and restrictions, numerous optional language extensions, 
optional extensions for floating-point math, string handling, 
programming tools, additions to facilitate porting programs 
across disparate CPUs, and an optional interface between 
Forth and operating systems like UNIX, VMS, OS-2, and MS-DOS. 
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Letters to the Editor— and to your fellow readers — are always welcome. 
Respond to articles, describe your latest projects, ask for input, advise 
the Forth community, or simply share a recent insight. Code is also 
welcome, but is optbnal. Letters may be edited for clarity and length. 
We want to hear from you! 



Marketing vs. Objectivity 
& Public-Domain Glut 

I agree with many of the 
points mentioned in "Sing- 
apore Slingshot Targets FIG 
Issues" Getters, FDXm/4\ I 
do not see anything wrong 
with self-serving articles by 
Forth vendors. I certainly 
hope that FD readers are 
mature enough not to need 
to be "protected" from mar- 
keting hype. Many success- 
ful and well-respected trade 
journals are full of articles 
touting particular vendors' 
products. So long as the 
company affiliation of the 
author is identified, I have 
no problem distinguishing 
an "objective" article from a 
"marketing" article, and I read 
both kinds with interest. 

I take issue with Mr. Tse's 
point number 19, in which 
he suggests another "model" 
system. In my opinion, the 
last thing the Forth commu- 
nity needs is Yet Another 
Public-Domain Forth. There 
are way too many public- 
domain Forths already, and 
creating another one will 
further erode the ability of 
the few Forth vendors that 
are left to make a living. The 
Forth community needs 
profitable vendors, because 
profits result in money that 
can be spent on advertising 
and marketing. Forth des- 
perately needs visibility, and 
like it or not, visibility results 
from dollars spent on mar- 
keting. 

Furthermore, it is ex- 
tremely unlikely that the ex- 
isting Forth vendors who 
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have managed to stay in 
business for several years 
would switch to the pro- 
posed "super-duper" Forth 
system. 

Forth to the Future, 
Mitch Bradley 
Bradley Forthware 
P.O. Box 44 

Mountain View, CA 94040 

We Must Not Do Nothing 

Dear Marlin, 

Forth is the artist's lan- 
guage. It allows us to tap the 
computer's true potentials 
and create things of beauty — 
beauty in simplicity, con- 
ciseness, elegance, and 
speed. Is there anything more 
satisfying than creating a 
powerful algorithm, which 
does exactly what it is sup- 
posed to do, using about 
half-a-dozen words? 

Forth has been around 
for two decades now, and 
many brilliant contributions 
have been made by the Forth 
community. Yet, despite the 
sustained efforts of many, 
there has been no wide- 
spread recognition and use 
of Forth. 

Many explanations can 
be found for this. However, 
it does no good to speculate, 
feel sorry for ourselves, or be 
righteously indignant, if this 
doesn't lead to improved 
conditions. 

Judging by recent FD ar- 
ticles, such as last issue's 
President's Letter ("I Have a 
Dream") and Mr. Tse's letter 
for the editor ("Singapore 
Slingshot..."), I believe that 
Forth is an idea whose time 
has come. These letters ex- 



press a desire to change 
things for the better. I think 
that most of us share that 
sentiment. 

The difference between 
Forth fading into obscurity 
and Forth becoming the 
foremost innovative force in 
the computer industry lies in 
what we, as individual FIG 
members, do about it. The 
one thing we must not do is 
nothing. 

All of us have unique 
talents that we can contrib- 
ute to help Forth expand. Let 
us, then — each of us — do 
something, no matter how 
small initially, to get the ball 
rolling. By doing so, we will 
eventually reap the rewards. 
Imagine the satisfaction of 
having our children or 
grandchildren say, "Wow, 
you were one of the guys 
who put Forth on the map!" 

Peter Verhoeff 
P.O. Box 10424 
Glendale, California 91209 

Forth on a Bathroom 
Scale — No Lightweight 

Dr. Ting's letter to Mr. 
Koopman (.FD XIII/3) in- 
spired me to share my feel- 
ings about Forth and its fu- 
ture. 

A few years ago, I started 
working at a thin-film circuit 
startup. The boss like Forth. 



Make that loved Forth. 
Therefore, I was dragged 
kicking and screaming into 
what turned out to be a really 
great language. My only in- 
struction came from Mr. 
Brodie's Starting Forth. (I 
think Brodie deserves some 
kind of award for his contri- 
bution to Forth.) I had never 
taken a computer course. 

In my four years with the 
company using Forth (first 
F83, and later LMI Forth), I 
managed to: 

• From scratch, build an au- 
tomated wafer-probing 
machine that tested hun- 
dreds of points on a semi- 
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conductor wafer, "learned" 
from the operator, and 
saved the test results to 
disk. 

• Write the operating soft- 
ware, with a graphics in- 
terface, for a custom semi- 
automated, thin-film sput- 
tering machine. Some 
amount of artificial intelli- 
gence was used in this 
project. 

• Computerize a Dektak 
film-thickness profiler. 
Profiles were drawn in real 
time on a CRT, and could 
be zoomed in on, saved to 
disk, etc. The operator 
controlled the machine 
with a mouse. 

• Starting with a bathroom 
scale, built an adhesion 
tester that measured film- 
to-wafer adhesion strength. 
A computer displayed the 
adhesion strengths in PSI 
and Pascals. 

• Get a Harris RTX-2000 Forth 
engine interfaced to a liq- 
uid crystal display and 
drawing graphics. 

Software development 
with Forth was fast. I usually 
had something coming to 
life in a matter of hours. 
Modifications were some- 
times made practically in real 
time, while the machines 
were in production use. 

Well, enough of the real- 



world applications of Forth. 
At issue is, why does its 
future look somewhat dis- 
mal, and what does it need 
to succeed? 

1. It is reasonably well 
marketed. 

2. It has a professional 
programming environ- 
ment (vs. F83). 

3- It is available in versions 
with a street price under 
$100. 

When these requirements 
are met, people are more 
likely to spend the few dol- 

(Letters continue on page 13 ) 
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It was a dream come true. 
It was a nightmare. 



Yerk Comes to 
the PC 

Rick Grehan 

Peterborough, New Hampshire 



Some time ago, I discov- 
ered a Forth-based, ob- 
ject-oriented program- 
ming system for the Macin- 
tosh called Neon. For what- 
ever reason, Neon was dis- 
continued. Recently, how- 
ever, the language has reap- 
peared in the public domain 
as "Yerk," largely due to the 
work of Bob Loewenstein at 
the Yerkes Observatory 
(hence the new name). 

I have always been im- 
pressed by Yerk's object-ori- 
ented abilities. Though I 
continue to work on the 
Macintosh, I do enough in 
MS-DOS that I began to wish 
for something like Yerk on 
the PC. So I wrote PCYerk, a 



Rick Grehan is a senior editor at BYTE 
magazine, where he is the technical 
director of BYTE Lab. He first encoun- 
tered Forth over seven years ago when 
developing a music synthesizer con- 
trol system builtaround a KIM-1 . Since 
then, he has used Forth on 68000 
systems (including the Macintosh), the 
Apple II, and the IBM PC. He has also 
doneextensive work on theSC32 stack- 
based processor. Rick has a B.S. de- 
gree in physics and applied math- 
ematics, and an M.S. degree in math- 
ematics/computer science. 
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moderately complete dupli- 
cation of the Yerk syntax for 
the PC. I say "moderately" 
because there are some Yerk 
capabilities — not counting all 
the Mac toolbox routines 
Yerk has access to — that 
PCYerk does not support 

I've written PCY erk using 
Upper Deck Forth, a 16-bit 
multisegmented Forth for PCs 
running MS-DOS. It's likely 
that someone well-versed in 
F-PC could easily port Yerk 
to that system. I'll use this de- 
scription of PCYerk as a ve- 
hicle for introducing you to 
some object-oriented conospts. 

Objects and Classes 

An object is a combina- 



tion of code and data that 
your program can treat as an 
indivisible entity. The code 
associated with an object is 
really a collection of routines 
that manipulate that object's 
data and allow that object to 
interact with other objects in 
the program, I/O devices, 
and other parts of the sys- 
tem. 

A class is a kind of tem- 
plate for an object. The class 
definition describes the me- 
chanics of offspring objects, 
and consists of two main 
pieces: the methods (what 
objects know how to do) 



and the instance variables 
(an object's local data). 

When you create an ob- 
ject, we say that the object 
has been instantiated: the 
class template has forged 
something real (as real as 
any piece of code can get). 
Once you have instantiated 
an object, you can make 
that object do things by 
sending it messages. For- 
mally, a message is com- 
posed of two parts: a selector 
and some attendant data. 
The selector is an ID num- 
ber that the object uses to 
determine which method to 
execute. In PCYerk, there's 
little difference between 
message and selector. The 
message is the selector; any 
data is passed on the pa- 
rameter stack. 

In PCYerk, the defining 
word for a class is : class. 
ListingOne shows the source 
code for a simple class called 
integer. Notice that the 
class definition is bracketed 
by : class and /class (I'll 
explain the other parts of the 
definition later). These two 
words serve to encapsulate 
the class definition. 

Instance Variables 

As I mentioned, instance 
variables define the local 
storage associated with an 
object If you look again at 
Listing One, you'll see that 
objects of the class integer 
possess a single instance var- 
iable: localdata. The word 
i va r expects a value on top 



of the stack that indicates the 
number of bytes to be allo- 
cated by the current instance 
variable — whose name ivar 
parses from the input stream. 
Whenever you create an 
object of type integer, the 
system knows to allocate two 
bytes of variable space. 

Instance variable names 
last only as long as the class 
definition. In other words, 
upon execution of the code 
in Listing One, the symbolic 
name localdata is dis- 
carded (the word ; class 
does this). 

Messages and Methods 

Objects of class integer 
understand two messages, 
get : and put : . Each of these 
messages corresponds to a 
method of the same name. I 
can create an object of type 
integer and store a 12 in it 
with: 

integer myint 

\ Create the object 

12 put : myint 

\ Send a put : message 

As you've probably 
guessed, I can retrieve the 
contents of myint using the 
get : message. The only way 
a program can legitimately 
manipulate the instance data 
of myint is via get : and 
put : . I say "legitimately" here 
because a clever Forth pro- 
grammer can manipulate 
anything. Object-oriented 
programming guidelines, 
however, discourage low- 
level manipulation of an 
object's interior except by 
that object's messages. 

Sometimes you need an 
object to automatically ex- 
ecute a method when that 
object is instantiated. A good 
example would be an array 
class whose initialization 
method allocates space for 
the array, then stores in an 
instance variable the num- 
ber of members allocated to 
that array. 

The PCYerk syntax for 
setting an initialization 
method is shown in Listing 
Two, where I've defined a 
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Guidelines discourage low-level 
manipulation of an object's 
interior, except via messages. 



Listing One. Source 
code for a simple class. 



: class integer 
2 ivar localdata 

:m get: ( — n ) 
localdata @ 

;m 

:m put : ( n — ) 
localdata ! 

;m 

/class 



method called clear:, 
which stores a zero in the 
local data. You must place 
the «init-method word 
prior to /class. 

Listing Two also shows 
the use of the self word. 
This allows an object to ref- 
erence itself in a method 
definition. It's as if the 
clear : method were say- 
ing: "Okay, object, here's a 
zero on the stack. Now send 
a put : message to yourself." 

Inheritance 

Inheritance is one of ob- 
ject-oriented programming's 
big buzzwords. The concept 
is simple enough: you start 
with simple classes and build 
on those to create classes 
that are incrementally more 
complex and specialized. 
Each new class within an 
inheritance chain carries all 
the knowledge (i.e., meth- 
ods and instance variables) 
its ancestors carry. 

For example, suppose I've 
defined a class called 
ldarray that allows you to 
create a one-dimensional 
array. Objects of this class 
would have methods to allo- 
cate array space, store a value 
to an index location, and 
retrieve a value from an in- 
dex location. 

Next, I define a class called 
$ptr_array that manipu- 
lates an array of string point- 
ers. I want this new class to 
know how to manipulate a 
one-dimensional array 
(something ldarray can 
do), but it should also be 
able to print a string. In short, 
I want objects of the 



Listing Two. 

Initialization and self- 
referencing. 



:m clear: ( — ) 
put : self 

;m 

clear «init-method 



$ptr_array class to inherit 
the abilities of the ldarray 
class, then add some string- 
handling capabilities. 

PCYerk provides inherit- 
ance via the <super word. 
Usage goes like this: 

: class 
$ptr_array 
<super ldarray 

which defines a new class 
$ptr_array whose super- 
class is the class ldarray. 

The <super word does 
a number of things. First, it 
stores a link in the class- 
definition header. This link 
points to the class-definition 
header of the superclass. 
Whenever an object receives 
a message, that object first 
searches its class's methods 
list If it can't find the method 
corresponding to the mes- 
sage, the system follows the 
superclass link and searches 
the superclass's methods list 
This process continues until 
either the method is found or 
all classes on the chain have 
been searched. Such are the 
mechanics of methods in- 
heritance. (Notice that, since 
the search takes place for 
local methods first, an object 
can redefine an inherited 
method.) 

Next, <super initializes 
the class's instance variable 
space accumulator with the 
amount stored in the 
superclass's. In other words, 
a class inherits the instance 
variable space requirements 
of its superclass. 

Finally, <super sets the 
class's initial method to the 
initial method of the super- 
class. The class inherits its 
superclass's initial method. 
As described above, you can 
override that initial method 
with the «init-method 



word. 

Inheritance is the basis 
for polymorphism, yet an- 
other piece of object-oriented 
jargon. Polymorphism means 
that different offspring of a 
given superclass respond to 
the same message selector 
differently. I might define a 
subclass of integer called 
integer_array. An in- 
teger object would respond 
to the get : message by re- 
trieving the value in the single 
instance variable. Meanwhile, 
an object of class 
integer_array would re- 
spond to the same message 
by retrieving an index value 
from the stack and fetching 
the appropriate array ele- 
ment Same message selec- 
tor, different action. 

Binding 

Binding is the process of 
taking a message's selector 
and determining the execut- 
able address (i.e., the 
method) associated with that 
selector. Of course, the 
method depends on the ob- 
ject class you're sending the 



message to. There are two 
kinds of binding: early bind- 
ing and late binding. 

You've already seen early 
binding; it looks like this: 

get : my_integer 

which retrieves the contents 
of my_integer. The sys- 
tem knows the message 
(get:) and the object 
(my_integer) and can, 
therefore, locate the execu- 
tion address of the method 
corresponding to the mes- 
sage at compile time. 

(Internally, when the 
system encounters a mes- 
sage selector name, it places 
a l6-bit ID number on a 
special stack called the 
method stack, or mstack 
for short. When it encoun- 
ters an object name, the 
system places the object's 
address on another special 
stack, the object stack — 
ostack — and transfers 
control to the word exec- 
ob j , which pops the mstack 
and performs the binding. 
While the method executes, 
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instance variables can re- 
solve their addresses by cal- 
culating offsets from the 
object address on the 
ostack.) 

Late binding is also re- 
ferred to as deferred bind- 
ing. In simple terms, it means 
the system doesn't know 
what object you're going to 
send a message to. Hence, 
the system can't bind the 
message to an execution 
address at compile time. 

Here's an example of 
PCYerk's late binding: 

get : { integerob j @ } 

Here, I'm assuming that 
the variable integerobj 
holds an object's address. At 
compile time, there's no way 
the system can know what 
object will be in intege rob j 
when the program executes. 
The system must, therefore, 
determine the execution ad- 
dress of get : at run time. 

The words to handle late 
binding are { and }. (Yerk 
used [ and ] , butthose words 
were already taken in UD 
Forth.) The curly brackets 
should immediately follow 
the message, and may en- 
close any Forth expression 
that yields an object's ad- 
dress. 

Of course, late binding 
yields code that runs more 
slowly than code using early 
binding. This is because late 
binding defers until run time 
processing that would have 
been performed at compile 
time. 

Late binding lets you — 
with only minor additional 
programming — bypass one 
of PCYerk's deficiencies: 
namely, that you define all 
instance variables using the 
ivar word. You cannot use 
an object as an instance vari- 
able. Suppose you've defined 
a class called ldarray that 
lets you build one-dimen- 
sional array objects, and a 
class called polygon that 
builds polygon objects. It 
would be nice to have a 
ldarray object as one of 
the instance variables of the 



Figure One. Class header structure. 
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Listing Three. Building a headerless object. 



: class polygon <super object 
2 ivar A vertex_list 

\ Allocate space for vertex list 

:m init: ( n — ) 

2* \ 2 coordinates per vertex entry 

here dup ~vertex_list ! [ ' ] ldarray >body @ 
instantiate 

;m 

init : «init-method 

:m ->vertex: ( y x i — ) 

2* \ Index * 2 for x and y coordinates 

tuck \ Get a second copy of the index 

to: { "vertex_list @ } \ Store x 

1+ \ Advance index to next slot 

to: { ~vertex_list @ } \ Store y 

;m 

; class 
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Listing Four. PCYerk source code. 



\ PCYerk 

\ Object-oriented extensions to Forth 

\ a la Yerk (once, NEON) 

\ Written for Upper Deck Forth, version 2.0 

\ R. E. Grehan 

\ Sorry, I can't stand "then" 

: endif [compile] then ; immediate 



\ Used in parsing names 



\ ************* 

\ ** STORAGE ** 
\ ************* 

34 $variable tstring 

\ Method stack 

20 constant METH_ST ACK_S I ZE 

create mstack 

METH_STACK_SIZE allot 

\ Objects stack 

20 constant OBJ_STACK_SIZE 

create ostack 

OBJ STACK SIZE allot 



\ Instance variable names segment 
variable ivar_seg \ Segment 

20 constant IVAR_SEG_SIZE \ Segment size in paragraphs 

variable ivar next \ Offset to next free loc. 



\ Methods names segment 
variable methname_seg 
100 constant METHNAME_SEG_SIZE 
variable methname_next 
variable curr_meth# 
variable my_meth# 

\ Class definitions 
variable curr_class_of f 
variable curr meth tail 



\ Segment 

\ Segment size in paragraphs 
\ Offset to next free slot 
\ Current method # 
\ Method # about to be defined 



\ Offset to current class 
\ Current method tail 



\ ****************************** 

\ ** METHOD AND OBJECT STACKS ** 

\ ****************************** 

\ NOTE: Neither stack do any bounds checking (for speed's 

\ sake) . If bounds checking is added, the stack manipulation 

\ words should be written in machine language. 



\ Initialize the method stack. 
: mstack-init ( — ) 

mstack dup ! 



.stores selector ids 



\ Push top word onto method stack 
: mpush ( n — ) 



mstack @ 2+ 
2 mstack +! 



\ Copy top of mstack to dstack 
: mstack->dstack ( — n ) 
mstack @ @ 



\ Save item 
\ Increment 



(Listing continues.) 



polygon class. Then you 
could store the polygon's 
vertex list into the one-di- 
mensional array object. 

It turns out you can do 
this by defining one of the 
polygon's instance variables 
to be a pointer to an object of 
class ldarray. Essentially, 
you build a headerless ob- 
ject; that is, one that does not 
have a head in the Forth 
dictionary. The word in- 
stantiate will build such 
a headerless object. All in- 
stantiate needs on the 
stack is a starting address in 
the variable region (where 
the new object will go) and 
a pointer to the class defini- 
tion. The code showing this 
technique is in Listing Three 
(which presumes thatyou've 
defined the ldarray class 
already). 

Notice that I've defined 
init : to multiply the num- 
ber of vertex entries by two, 
since the vertex list will carry 
an x and y coordinate for 
each vertex. The next line 
stores the address of the next 
free location in the variable 
segment into 
A vertex_list, which be- 
comes a pointer to our one- 
dimensional array. I then use 
[ ' ] to retrieve the code ad- 
dress of the ldarray class, 
then fetch the address of that 
class definition. The in- 
stantiate word actually 
creates the array. Keep in 
mind that, when instan- 
tiate executes, the 
ldarray object's initial 
method — which allocates the 
memory space — will be ex- 
ecuted. 

Now we can store an x 
and y coordinate into the 
ldarray object using a 
method called to:, which 
we've presumably already 
defined for the ldarray 
class. You can extend this idea 
as far as you'd like to go, 
creating pointers to objects with 
pointers to objects, and so on 

Nuts and Bolts 

Refer to Listing Four, the 
complete source for PCYerk. 
The heart of PCYerk is 
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: class. The : class word 
uses a nested create ... 
does> structure — the kind 
that makes my head hurt 
whenever I have to think 
about it At compile time, 

: c la s s builds a class header 
structure as shown in Figure 
One. 

I have to take a moment 
here to describe something 
of the structure of UD Forth. 
Being on the IBM PC, UD 
Forth has a segmented archi- 
tecture. Executable code re- 
sides in the code segment, 
variables are stored in the 
variables segment, threading 
pointers are kept in the to- 
kens segment, and names 
are kept in the headers seg- 
ment. Names built using 
Forth's create word return 
a pointer to a parameter field 
in the variables segment, 
hence the class pointer in 
that segment for a class defi- 
nition. 

The first field in the 
header — ivar space — tells 
the system how much space 
to set aside for instance vari- 
ables when an object is cre- 
ated. The second field is the 
head of a linked list that 
connects all the methods for 
a particular class. Next comes 
the superclass pointer field, 
which is set by the <super 
word, and which provides 
the means by which a class 
inherits methods from its su- 
perclass. The last word of the 
class header is the start selec- 
tor; itidentifies which method 
will be automatically ex- 
ecuted when you create an 
object 

Objects carry execution 
addresses defined by the 
code following the second 
does>in : class. When you 
send an object a message, 
the system follows the pointer 
to the class header, then 
searches down the methods 
list chain (as described above) 
to determine what code to 
execute. Notice that the code 
for a method is absolutely 
headerless; a method doesn't 
even possess code field ad- 
dresses. A special word — 
(domethod) — executes a 



(PCYerk Listing Four, continued.) 



\ Fetch 

\ Decrement 



\ Save item 
\ Increment 



\ Pop top word from method stack 
: mpop ( — n ) 

mstack->dstack 

-2 mstack +! 



Initialize the object stack 
ostack-init ( — ) 

ostack dup ! 



Push top word onto object stack 
opush ( n — ) 

ostack @ 2+ ! 
2 ostack +! 



Copy top of ostack to dstack 
ostack->dstack ( — n ) 
ostack @ @ 



Pop top word from object stack 
opop ( — n ) 

ostack->dstack 
-2 ostack +! 



Dup top of object stack 
odup ( — ) 

ostack->dstack 
opush 



\ Drop top of object stack 
: odrop ( — ) 

opop drop 



\ Clear both stacks. 

\ Use this if something aborts and you don't want the 
\ stacks growing forever. 
: clear-o&mstacks 

ostack-init 

mstack-init 



\ ************************ 

\ ** TEMPORARY SEGMENTS ** 
\ ************************ 

\ The method names and instance variable names are kept in 

\ temporary segments . These segments are allocated 

\ from DOS. When you're done defining things and 

\ its time to make an executable, just free those 

\ segments. (The word 'end-objects', defined later, 

\ does all that . 

\ Compare two counted strings, segl addrl, seg2 addr2 point to 
\ segment and addresses of two strings with preceding count 
\ bytes. Returns if equal, else nonzero 
: ccompl ( segl addrl seg2 addr2 — n ) 

\ First check byte counts 

countl >r 2swap countl r@ = 



\ Fetch 

\ Decrement 



\ Fetch top 
\ and push 
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if 

else 
endif 



r> compl 
4drop r>drop 1 



\ Lengths match... try comparison 
\ Show mismatch 



\ Advance to next item past the current counted string. 
\ seg: addr points to counted string. Takes into account 
\ trailing integer. 

: nextstr ( seg addr — seg addr' ) 
count 1 +2+ 



\ Search one of the temporary segments . 

\ segl:addrl points to string to search for 

\ seg2 is temporary segment to search 

\ max is maximum current offset in segment . 

\ n is returned associated integer; -1 means 

\ the string was not located. 

: search-tseg ( segl addrl seg2 max — n ) 



dup 
if 



>r 


begin 



endif 
4drop 
-1 



2over 2over 

ccompl 

0= 

if 2 swap r> 3drop 
countl + @1 
exit 

endif 

nextstr 

dup r@ >= 
until 
r>drop 



\ Anything to look for? 
\ Save max 

\ Start search at zero 

\ Dup seg/address 
\ Look for match 

\ Clear stack 
\ Fetch value 



\ Advance to next string 

\ Topped out? 

\ Clear return stack 

\ Clear stack 

\ Show error 



\ ** 

\ ** Instance variable segment handling 
\ ** 

\ The ivar segment is a temporary region where the system 
\ keeps a list of the current class definition's instance 
\ variables. Each entry is composed of a length byte, the 
\ name, and a 2-byte value that indicates that instance 
\ variable's offset into an instance of the class 

\ Allocate space for the IVAR segment . Place the segment 
\ in global variable ivar-seg 
: alloc-ivar_seg ( — ) 

IVAR_SEG_SIZE alloc 

error 

if abort" Ivar allocation error" 
endif 
ivar seg ! 



\ Fetch error 
\ Save pointer 



\ Clear the ivar segment 
: clear-ivar_seg ( — ) 
ivar next ! 



(Listing continues.) 



method by mimicking the 
run-time action of the colon 
word. You pass (dometh- 
od) the starting address of 
the method code and it 
handles the rest. 

PCYerk does not create 
standard Forth headers (a la 
create) for instance vari- 
ables and methods. In the 
case of instance variables, 
you want their names to dis- 
appear after the class defini- 
tion. For method names, you 
don't want their names tak- 
ing up header space, since 
they are instantly resolved to 
two-byte selector ID num- 
bers. 

PCYerk allocates two 
memory blocks (using the 
UD Forth word a Hoc, which 
provides access to the DOS 
function for allocating a 
memory segment): one to 
hold instance variable names, 
the other to hold method 
names. Each name stored in 
one of these blocks is associ- 
ated with an integer. 

In the case of instance 
variables, the associated in- 
teger carries that instance 
variable's offset into the 
object's local data space. At 
compile time, when the sys- 
tem encounters an instance 
variable, it looks up the 
variable's offset and com- 
piles that as a literal, fol- 
lowed by the word ( i va r ) . 
Atruntime, (ivar) takes the 
offset from the stack and 
resolves that offset to an ad- 
dress. 

In the case of methods, 
the associated integer is the 
selector ID number. When 
you define a new method's 
name, the system increments 
an internal counter and the 
incremented value becomes 
that method's ID number. 
This ensures a unique ID 
number for each method. 
(Y erk used a hashing method 
to generate such ID num- 
bers. I chose a separate route, 
since the code for handling 
instance variable names and 
method names was so simi- 
lar.) 

But wait. If the system 
puts method names and in- 
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stance variable names in 
these alternate segments, 
how does Forth find those 
names during compilation? 
You have to patch inter- 
pret. 

In UD Forth, interpret 
first tries to find the word in 
the dictionary. If that fails, 
interpret tries to parse 
the word as a number. If the 
number conversion routine 
can't digest it, interpret 
executes do-undefined 
(which prints out the offend- 
ing word and executes 
quit.) I overwrite the call to 
do-undefined to point to 
<interp-patch>. The 
<interp-patch> word 
(see Listing Four) looks first 
in the method segment, then 
in the instance variable seg- 
ment. If <interp-patch> 
finds the word in either seg- 
ment, it takes appropriate 
action. Of course, <interp- 
patch> ultimately falls 
through into do -unde- 
fined. 

You have to execute 
start-objects before you 
begin defining any classes. 
The start-objects word 
allocates and initializes the 
instance variable and method 
names segments, then 
patches interpret and 
clears the methods and ob- 
jects stacks. Finally, when 
you're ready to create a stan- 
dalone application, execute 
end-objects. This 
repatches interpret to put 
it back the way it was, and 
releases the allocated 
memory blocks (which are 
unnecessary in the run-time 
code.) 



(PCYerk Listing Four, continued.) 



\ Given that addr points to a counted string that represents 

\ an instance variable name, return the associated offset. 

\ If you can't find that variable, return a -1. 

: search-ivar ( addr — n ) 

vars swap \ String is in vars segment 

ivar_seg @ \ Search through ivars segment 

ivar_next @ \ Max. to look for in ivar segment 

search-tseg \ Search a temp, segment 



\ addr points to a counted string that represents an instance 
\ variable name, n is the offset to attach to that instance 
\ variable. Add this name to the list. 
: add-ivar ( n addr — ) 
dup c@ >r 



vars swap 

ivar_seg @ ivar_next @ 
$!1 

ivar_seg @ ivar_next @ r@ + 1+ 
r> 3 + ivar next +! 



!1 



\ Save byte count 

\ Source address 

\ Destination 

\ Copy the string in 

\ Store associated value 

\ Advance next 



\ ** 

\ ** Methods name segment handling 

\ ** 

\ The methods segment looks a lot like the IVARS segment . 

\ it holds the list of methods defined within the system. 

\ Associated with each method name is a unique 2 -byte 

\ id. 



\ Allocate space for the method name segment 
: alloc-methname_seg ( — ) 
METHNAME_SEG_SIZE alloc 

error \ Fetch error 

if abort" Methname allocation error" 

endif 

methname_seg ! \ Save pointer 



\ Clear the method segment 
: clear-methname_seg { — ) 
methname next ! 



\ Search for a method in the methods segment. 
\ not found. Else return method # 



Return -1 if 



methname-f ind 
vars swap 
methname_seg 6 
methname_next @ 
search-tseg 



( addr — n ) 

\ String is in vars segment 
\ Search through ivars segment 
\ Max. to look for in ivar segment 
\ Search a temp, segment 



\ Add a new method to methods segment . 
\ method as the method's id 



add-methname ( n addr — ) 
dup c@ >r 
vars swap 

methname_seg @ methname_next @ 
$!1 

methname_seg @ methname next @ 



r@ 



Associate n with that 



\ Save byte count 
\ Source address 
\ Destination 
\ Copy the string in 
+ 1+ !1 

\ Store associated value 
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r> 3 + methname next +! 



\ Advance next 



\ *************** 

\ ** METHODS ** 
\ *************** 

\ Methods are kept on singly-linked list. That list is anchored 

\ in the class definition structure defined below. Each entry 

\ on a method list looks like this : 

\ Token segment 

\ [ link to next ] 

\ [ Method id # ] 

\ [ • • .tokens ] 

\ Attach a new method to tail, addr on top of stack is assumed 
\ to be pointer into token segment 
: new-method-tail ( addr — ) 

\ See if we are first method added. If so, attach to parent. 

curr_meth_tail @ ?dup 0= 

if dup \ Copy ourselves 

curr__class_of f @ 2 + 
!t 

else over swap !t \ Fix link 

endif 

curr meth tail ! \ We are new tail 



\ (>super) 

\ This routine looks 'up the chain' to an object's super object 

\ Used when searching for methods to execute . 

\ addrl is the current object's address in the token seg. 

\ addr2 is the super object's address or if none found 

: (>super) ( addrl — addr2 ) 

4 + @t \ Fetch the super object address 



\ (domethod) 

\ Following code word vectors execution to a method. 
\ Assumes that the value on top of the stack is offset 
\ into token space for the method, 
code (domethod) ( off — ) 

bp dec \ Make room on return stack 

bp dec 

si [bp] mov \ Push IP 

bx si mov \ Get method address in IP 

bx pop \ Pop stack 

next \ Take off ! 

end-code 

\ domethod 

\ Calls (domethod) and clears the object stack. 
\ Off is the address of the method code . 
: domethod ( off — ) 

(domethod) 

odrop 



\ (methid->addr) 

\ Given a method id, this finds that method's address in the 

\ token segment, addrl is the address of the object (in the 

\ token segment) whose method 

\ list we'll search. addr2 is the method address, or if the 

\ method wasn't found. 

(Listing continues.) 
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(Letters, from page 5) 

lars to at least give it a spin. 
Hobbyists will buy it. Small 
companies will try it. The 
word gets around. 

At this time, the low-cost 
versions of Forth are not at 
all well marketed — if you 
could say they're marketed 
at all. I have not used F-PC 
yet, but I assume it fixes the 
awful programming envi- 
ronment of F83. How can we 
expect people accustomed 
to the pleasant Microsoft 
Quick-x environments to 
accept F83? The slick, pro- 
fessional Forth versions are 
just too expensive to be- 
come popular. 

The same two solutions 
keep popping into mind: ei- 
ther Microsoft QuickForth or 
Borlund TurboForth. The 
successes of the Quick/Turbo 
BASIC, C, and Pascal pack- 
ages speak for themselves. 

At this time, I am learning 
C. I don't know if there's 
something wrong with me, 
or if it's due to my Forth 
experience, but I'm certainly 
very disappointed with the C 
language. Compared to 
Forth, C seems like a giant 
step backward. So why 
bother? To the "profession- 
als" in the personnel depart- 
ments, C is a recognizable 
"hot" buzzword on a resume, 
while Forth just looks like 
you can't spell. 

Finally, I hope the FIG 
dues increase to $40 will not 
be the death blow — but it 
just might It shouldn't cost 
$6.67 per issue to publish 
Forth Dimensions. Maybe it's 
time for a major re-thinking 
of the structure of the group. 

Sincerely, 

Steve J. Noll 

1288 Winford Avenue 

Ventura, California 93004 

The Atari Lesson 

Dear Editor: 

I notice two alarming 
trends in my latest issue of 
FL>. 1) circulation has drop- 
ped from an average 1934 to 
1750, and 2) a vendor is 
complaining about lack of 
support/hostile publication 

(Letters continue on next page.) 
January 1992 February 



rules. (Jim Callahan, Harvard 
Softworks; FD Xin/4). 

I believe 1) and 2) above 
are related. Without aggres- 
sive marketing (of both Forth 
products and FD itself), all 
previous creative efforts will 
wither on the vine. The 240 
million people in this coun- 
try have a lot of demands on 
their time. If Forth doesn't 
appear worth the effort, 
people won't invest the time 
to find out it is. Look at the 
success of the C program- 
ming community. As a dab- 
bler in both languages, I can 
vouch that there is no short- 
age of public relations on the 
C side. 

Therefore, I implore you 
and your staff to listen to 
these vendor complaints and 
take action. How about some 
articles comparing the vari- 
ous hardware Forths (Silicon 
Composers, etc.). How about 
articles comparing the ad- 
vantages and disadvantages 
of the various software Forths 
(polyFORTH, HS/Forth, 
MMS-Forth, etc.). How about 
inviting the vendors to de- 
clare the advantages of their 
systems in article form (they 
would probably be willing 
to pay for the opportunity. . .). 

Failure to take action will 
lead to suffering what I call 
the Atari lesson. In 1985, 
when I bought the computer 
I'm typing this letter on, the 
personal computer industry 
was just taking off. The Apple 
II was showing its age, the 
overpriced/underpowered 
IBM XT was carving a large 
market share, and the AT 
had just appeared. Probably 
the most popular computer 
was the very limited Com- 
modore 64. The most in- 
triguing computer out was 
the Apple Macintosh — a user- 
friendly machine which cost 
over $2000 (with student dis- 
count) for the 256 Kbyte 
standard. Into this maelstrom 
jumped a recently reorga- 
nized Atari with the ST. A 
window/mouse-driven ma- 
chine with a big cotorscreen 
and 512 Kbyte, all for less 
than $1000. It was a dream 



(PCYerk Listing Four, continued.) 



(methid->addr) 
swap 2+ 
begin 

@t 

dup 
while 

dup>r 

2+ @t 

over = 



if 



drop 
r> 4+ 
exit 



endif 
r> 

repeat 
2drop 



( addrl n — addr2 ) 

\ Advance to method pointer 

\ Fetch pointer 



\ Save copy 

\ Fetch id number 

\ Match? 

\ Clear method id # 

\ Point to code 



\ Ready for next loop 
\ Show failure 



( — code ) 



\ Get method id 

\ Fetch the object 

\ Address in token seg 

\ Get address 

\ Didja find it? 

\ Clear the stack 
\ Bug out 



\ find-method-code 

\ Expects a method id # atop the method stack and an object 
\ pointer atop ostack. Locates the method code and 
\ leaves it on dstack. In so doing, the method stack is popped. 
: find-method-code 
mpop 

ostack->dstack 


begin 

2dup swap (methid->addr) 
?dup 

if -rot 2drop 

exit 
endif 

(>super) \ Not found. . .go to super object 

?dup \ Any super object?? 

0= 
until 

clear-o&mstacks \ Clear the stacks 

abort" Method not found" 



\ Define a method. This word doesn't do a create... it 
\ loads the method name in the method segment (unless 
\ its already there) , then compiles the code at the 
\ end of the object definition. The code is linked to 
\ the preceding method for that object. 
: :m 

\ We must be defining a class 
curr_class_of f @ 0= 
if clear-o&mstacks 

abort" Method def . ouside class" 

endif 



.so fix the link 



\ We are the new method tail. 
\ code. 

here-t new-method-tail 
,t 



\ See if the method is in the method seg. If it is, 



\ return the method #. 
\ assign a number, 
blword 
tstring $! 

tstring methname-f ind 
dup -1 = 



, if not, add this method in and 

\ Parse the name 

\ Put it in tstring 

\ Look for the method 

\ Found? 
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if drop 

curr_meth# @ dup 
tstring add-methname 
1 curr_meth# + ! 

endif 



\ Clear stack 

\ Fetch current method ID # 

\ Add method to the class 

\ Bump current method ID # 



\ Store method # for ;m and set aside space in token seg 
my_meth# ! 
,t 

\ Now go ahead and compile the method code, 
[compile] ] 



\ End of method definition 
: ;m 

\ Store the method # so the system can find it 
my_meth# @ 

curr meth tail @ 2+ !t 



compile unnest 
[compile] [ 
; immediate 



\ Do a semicolon 

\ Set interpret state 



\ ************************** 

\ ** INSTANCE VARIABLES ** 
\ ************************** 

\ Define an instance variable. 
\ Used in the form: 
\ n ivar <name> 

\ n indicates # of bytes for this instance variable. 

: ivar ( n — ) 

blword \ Parse the name 

tstring $! \ Put it in tstring 

\ See if ivar already exists 

tstring search-ivar -1 <> 

if abort" Ivar already defined" 

endif 

\ Fetch current offset — add it and ivar to ivar space 
curr_class_of f @ dup @t dup 
tstring add- ivar 

\ Update ivar space for next offset 
rot + 
swap ! t 



\ This code does the actual instance variable processing. 
\ When he executes, he expects the offset of an instance 
\ variable on the data stack. He also expects an object 
\ address (in variable segment) on the ostack. 
\ The returned addr is the offset to the instance variable 
: (do-ivar) ( off — addr ) 

ostack->dstack 

2+ 

+ 



\ Get object address 
\ Skip pointer to token seg 
\ Add offset 



\ *************** 

\ ** CLASSES ** 
\ *************** 



(Listing continues.) 
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come true. It was a night- 
mare. The aggressive mar- 
keting of IBM and Apple 
soon gobbled up the whole 
market. Software sources 
dried up. With money from 
huge sales, Apple and IBM 
improved their machines, 
leaving Atari in a non-com- 
petitive position. Now they 
make PC clones to stay alive. 

Does this sound familiar, 
Forth programmers? How 
many of you use C profes- 
sionally and Forth on the 
side? In 1985, the Atari ST 
delivered not only the best 
bang for the buck, but (to 
me) it was the all-around 
best computer available — 
speed, memory, display, in- 
terface, etc. Now I envy '486 
EISA machines with MS-DOS 
5.0 and Windows. There is a 
deadly parallel here to what 
has happened in the Forth 
community. The secret: to 
cut costs, Atari didn't invest 
in marketing, resulting in a 
product nobody heard of. 

In last issue's editorial, 
guest Horace O. Simmons 
recommended that Forth 
users promote Forth in non- 
Forth journals. That's an ex- 
cellent idea. How about pro- 
moting it in our owa' 

John H. Lee, Lt. USN 

QuikFind Addendum 

Dear Editor, 

While browsing through 
my article ("QuikFind String 
Search," FDXHl/4), I noticed 
a couple of errors and 
(heaven forbid) an error in 
the code listing. Here is a list 
of corrections: 

1. Page 21, hash algorithms 
figure. Captions reads, 
"...After each XOR, the 
bits in e index," which 
should be "". . .After each 
XOR, the bits in the in- 
dex...." 

2. Page 23, definition of HASH 

reads: 

D177 ( magic seed ) 
SWAP 

COUNT IF AND 

but should read as: 

COUNT IF AND 
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D177 ( magic seed ) 
SWAP 

3. Page 24, fig-Forth to 
botForth definitions, 
reads: 

: END IF ( sys — ) 
\ LITERAL 
\ DO ; IMMEDIATE 

but should read 

: END IF ( sys — ) 
\ THEN ; IMMEDIATE 

: FOR (sys — ) 
\ LITERAL 
\ DO ; IMMEDIATE 

Also, there is no defini- 
tion for @+. It can be ex- 
tracted from the definition 
for C@+. In a fig-Forth sys- 
tem, I believe the equivalent 
for RECURS ive would be to 
SMUDGE the latest definition, 
since SMUDGE merely 
toggles a bit In my definition 
of : (colon), I preceded 
RECURS IVE with a \ since it 
is an immediate word in 
botForth. 

Since writing this article, I 
have another another word, 
D ICT IONARY, which creates 
an instance of a hash table. 
This allows multiple hash 
tables to be created. Also, 
the hash tables are dynamic. 
They initially occupy no RAM 
but, as entries are added to 
them, they grow geometri- 
cally to accommodate the 
number of entries. EMPTY 
empties the table and returns 
the used memory. 

Another addition I have 
found very useful is the word 
ADJUNCT. This works just 
like QUIKFIND except it re- 
turns an entry in a parallel 
table where additional infor- 
mation may be stored about 
the string. Thus, you can 
associate a string with a block 
of code, another string, or 
whatever. 

If there is interest, I could 
publish the updated version 
of QuikFind. Right now, I am 
using it to build a translator 
which allows phrase defini- 
tions in Forth, instead of just 
words. Hopefully, more on 
that later. 

Rob Chapman 
January 1992 February 



(PCYerk Listing Four, continued.) 



\ exec-obj 

\ This fellow expects an object pointer (in vars segment) atop 
\ the object stack and a method # atop the methods stack. 
\ Executes an object's method 
: exec-obj ( — ) 

\ Find the method's executable code 

find-method-code 

domethod 



\ instantiate 

\ addrl is current pointe 

\ addr2 is object's token 

\ Stores that pointer in 

\ variable segment, then 

: instantiate ( addrl 



dup 
dup , 
@t 

allot 
6 + @t 
dup -1 <> 
if mpush 



else 



endif 



opush 
exec-obj 

2 drop 



r in var seg 

pointer 
the 

allocates ivars space. 
addr2 — ) 
\ Make copies of token pointer 

\ Store token pointer in var seg 

\ Fetch ivar space 

\ Allocate variable storage 

\ Fetch startup method 

\ Anything there? 

\ Push method 

\ Push object 

\ Execute stuff 

\ Drop -1 and object pointer 



** Class definition 
** 



\ The contents of a defined class are: 
\ Token segment: Vars segment: 

\ [ Ivars space ]< [ token ptr ] 

\ [ Meth list ] 
\ t Super ptr ] 
\ [ start meth ] 

\ [ . .tokens ] 

\ Note that the code following does> can do a @ and 
\ retrieve the offset into token space for the class 
\ definition structure. 
\ 

\ Once instantiated, an object looks like this: 



\ Token segment : 

\ [ (;code) ] 

\ [ here-c ] 

\ [ . .tokens ] 

: :class 

curr_meth_tail ! 

clear-ivar_seg 

create 

here-t dup curr_class_of f 

,t 
,t 
,t 

-1 ,t 

does> 
@ 

here swap 
create 

instantiate 



Vars segment 
[ token ptr 
[ ... ivars 



] «« To parent class 
] 
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\ No methods yet 

\ No instance variables 

\ Build the name field 

\ Set current class 

\ Build pointer in vars seg. 

\ Size of ivars region 

\ Pointer to list of methods 

\ Pointer to superclass 

\ Initial method 

\ Fetch token pointer 

\ Get current object pointer 

\ Make a header 

\ Instantiate the object 

Forth Dimensions 



does> 



immediate 

opush 

state@ 

if 

compile (lit) 

ostack->dstack 

rt 

compile opush 
compile (lit) 



else 



find-method-code 
»t 

compile domethod 
odrop 

exec-ob j 



\ Make the object immediate 

\ Get object ptr. on ostack 

\ We are compiling 
\ Compile obj ptr. as literal 
\ Get object pointer 
\ There's the pointer 
\ Compile an object push 
\ Another literal is 
\ method code pointer 
\ Get method's code pointer 
\ Compile that 
\ Code to execute method 
\ Don't need object anymore 
\ We are interpreting 
\ Execute the object 



endif 



\ Complete a class definition 
: ; class 

clear-ivar_seg 

curr class off ! 



\ No ivars segment 
\ No current class 



\ Special word that returns current object so object 
\ can send a message to itself. Use 'self inside 
\ the methods definitions to refer to the current object. 
: self ( — ) 

compile (lit) 

curr_class_of f opush \ Get current object 

find-method-code \ Locate method code 

,t \ Store as literal 

compile odup \ Dup object 

compile domethod \ Execute method 

odrop \ Clear object stack 

; immediate 

\ Define a class's super class. 

\ A class will inherit instance variable space, methods, and 
\ startup methods from the super class. A class can override 
\ methods and startup methods . 
: <super 

\ Find the object and resolve code address to token address 
blword find 0= 

if abort" Super object not found" 
endif 

>body @ dup 

\ Store token address into super pointer of current class 

curr_class_of f @ 4 + 

!t 

\ Copy ivars into local ivars 
dup @t curr_class_of f @ !t 
\ Copy initial method 
6 + @t curr class off @ 6 + !t 



\ Define initialization method. 

\ This routine expects a method id on the top of the method 
\ stack. It stores that method id as the object's startup 
\ method. 



(listing continues.) 
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Attention Forth Authors! 

Author 
Recognition 
Program 

To recognize and reward 
authors of Forth-related ar- 
ticles, the Forth Interest 
Group (FIG) has adopted 
the following Author Recog- 
nition Program. 

Articles 

The author of any Forth- 
related article published in a 
periodical or in the proceed- 
ings of a non-Forth confer- 
ence is awarded one year's 
membership in the Forth 
Interest Group, subject to 
these conditions: 

a. The membership 
awarded is for the 
membership year fol- 
lowing the one during 
which the article was 
published. 

b. Only one membership 
per person is awarded 
in any year, regard- 
less of the number of 
articles the person 
published in that year. 

c. The article's length 
must be one page or 
more in the magazine 
in which it appeared. 

d. The author must sub- 
mit the printed article 
(photocopies are ac- 
cepted) to the Forth 
Interest Group, in- 
cluding identification 
of the magazine and 
issue in which it ap- 
peared, within sixty 
days of publication. 
In return, the author 
will be sent a coupon 
good for the follow- 
ing year's member- 
ship. 

e. If the original article 
was published in a 
language other than 
English, the article 
must be accompanied 

(Continues on next page.) 
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by an Engish transla- 
tion or summary. 

Letters to the Editor 

Letters to the editor are, 
in effect, short articles, and 
so deserve recognition. The 
author of a Forth-related letter 
to an editor published in any 
magazine except Forth Di- 
mensions is awarded $10 
credit toward FIG member- 
ship dues, subject to these 
conditions: 

a. The creditapplies only 
to membership dues 
for the membership 
year following the one 
in which the letter was 
published. 

b. The maximum award 
in any year to one 
person will not ex- 
ceed the full cost of 
the FIG membership 
dues for the following 
year. 

c. The author must sub- 
mit to the Forth Inter- 
est Group a photo- 
copy of the printed 
letter, including iden- 
tification of the 
magazine and issue in 
which it appeared, 
within sixty days of 
publicatioa A coupon 
worth $10 toward the 
following year's 
membership will then 
be sent to the author. 

d. If the original letter 
was published in a 
language other than 
English, the letter must 
be accompanied by 
an English translation 
or summary. 



(PCYerk Listing Four, continued.) 



«init -method 
mpop 

curr_class_of f @ 6 
!t 



\ ********************** 

\ ** DEFERRED BINDING ** 
\ ********************** 



\ Deferred binding allow you to specify the object at runtime, 

\ rather than at compile time. 

\ { Starts deferred binding. He assumes there's a method # on 

\ top of the method stack. He copies that as a literal into 

\ inline code (along with an mpush) . 



{ 



state@ 
if 



endif 
immediate 



compile (lit) 
mpop , t 
compile mpush 



\ We are compiling 
\ Compile literal 
\ Get method # 
\ Compile mpush code 
\ Interpreting — do nothing 



\ } Concludes a deferred method. He assumes there will be 

\ (at runtime) a method # on top of the method stack and an 

\ object pointer atop the data stack. He pushes the object 

\ pointer onto the object stack, finds the method, and executes 

\ it. 



} 

opush 
exec-ob j 



\ Push object pointer 
\ Execute it 



\ *********************** 

\ ** PATCHES AND MISC. ** 
\ *********************** 

\ Following code is the patch to interpret . 

\ Allows system to recognize methods and instance variables . 
\ NOTE: When we get here, literal? has left 2 zeros on stack. 
\ For uniformity's sake... we pass them on along. 
: <interp-patch> 

2drop \ Clear stack 

\ See if the item in question is a method. If so, leave the 

\ method id # on the method stack 

here methname-f ind dup 

-1 <> 

if mpush exit \ Push the method # 

else drop 

endif 

\ Not a method — see if it ' s an ivar 
here search-ivar dup 
-1 <> 
if ?comp 

compile (lit) 
,t 

compile (do-ivar) 
exit 

else drop 
endif 



\ GOTTA be compiling 
\ Compile ivar value 

\ Compile ivar handler 



(Listing continues on page 21.) 
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This is very important, I 
will agree. 



News from the Forth RoundTable 




What is this language, Forth? 



Gary Smith 

Little Rock, Arkansas 



Yes, there is an ANS Forth 
in the process of being 
drafted. Yes, the Technical 
Committee has labored long 
and hard in its collective at- 
tempt to meet the conflicting 
demands of minimalist ver- 
sus maximalist, desktop user 
versus embedded-system 
implementor. Yes, many 
compromises have been ar- 
rived at and many ambigu- 
ities removed from the BA- 
SIS as it winds ever closer to 
becoming not only X3J14 
BASIS.xxx, but the final draft 
proposal manifest we all look 
forward to. [See dpANS Forth 
announcement, page 4 J 

As was pointed out in my 
last column — via exchanges 
gleaned from GEnie Forth 
RoundTable Category 10, 
Topic 25 — several questions 
are still being debated. In 
this issue, we examine dis- 
cussions in Category 10, 
Topic 12, "X3J14 Holding 
Pattern,'' to discover that even 
the question, "What exactly 
is this language, Forth?'' is 
subject to heated discussion. 
Maybe, when the dust has 
settled, we will discover the 
ultimate truth that Forth is an 
attitude and has nothing to 
do with standardization. 

Read on... 



Category 10: Forth 
Standards 

From: Doug Philips 
Re: Architecture and Imple- 
mentation 

John Wavrik writes: 

"The ANSI team has ap- 
Forth Dimensions 



parently not only invented 
a new language, but also 
a new concept in com- 
puter science: a language 
that manipulates data 
structures in a functional 
way but does not allow 
us to know what the data 
structures are. Sure 
doesn't sound like a good 
idea, does it? Certainly 
isn't a tested idea, is it'" 



Oh, come on now, X3J14 
didn't do this first, X3J1 1 did 
it, and they probably weren't 
even the first! How big is an 
integer (cell)? Implementa- 
tion defined, guaranteed to 
be at least n bits. How big is 
a long (2cell)? Implementa- 
tion defined, guaranteed to 
be at least wbits and m>n. 
I will admit that one needs to 
know something about the 
size of things (not structure!), 
so that, say, ' foobar '.will 
work (or not). Do I need to 
know anything about what a 
'-execution-token really is? 
No. All I need to know is the 
set of operators that take one 
(or more) as arguments and 
the set that can produce them. 
I believe the technical term is 
"abstract data type. " Can you 
do arithmetic on a ' -execu- 
tion-token' Yes, but it will 
not be portable. As the stan- 
dard is concerned with port- 
ability, it will not allow such 
action in a conforming pro- 
gram. 

"If one is to limit the ex- 
tensibility of Forth and 
rely upon vendor-sup- 



plied standard operators, 
then a great number of 
them must be supplied in 
the hopes of meeting as 
many needs as possible. 
Words like COMP ILE, and 
START: become ex- 
tremely important as an 
attempt to rescue some of 
the functionality of classi- 
cal Forth. Even then, one 
typically finds that the 
supplied operators do not 
do exactly what is needed. 
Sounds exactly like the 
trap that most conven- 
tional languages have 
fallen into, doesn't it' And 
Forth did have a viable 
solution, didn't it? And 
the ANSI team is propos- 
ing a language that ig- 



"I mention this word be- 
cause it is one in which 
deviant implementations 
have already appeared. 
There have been a host of 
messages in this 
newsgroup pointing out 
that some of my examples 
using START : do not 
work on other trial imple- 
mentations. All I can say 
is that I consulted the 
author before imple- 
menting mine. Inciden- 
tally, I don't think this will 
be unusual — I think that 
as more implementations 
of the proposed ANSI 
Forth appear, more de- 
viations will appear. It is 
almost an inevitable con- 
sequence of trying to 
specify operators while 
being fuzzy about what 
they operate on." 

Funny, I thought that was 
just the natural result of us- 
ing English. And of the fact 
that any group, having con- 
centrated on something for 
as long as any of the ANSI 
Technical Committees ITCs] 
do, will come to an under- 
standing that is not always 
transcribed in the first pass 
or two. In fact, ANSI takes 



Useful things that can't be 
done demonstrate weakness 
in the standard... 



nores this solution, isn't it?" 

Straw argument. If Forth 
had already had viable and 
/»rtaWgsolutions, there would 
be no "hard work" to doing 
an ANSI standard. (Nor, per- 
haps, a need to do one at all.) 

"Not only is it not easy to 
tell, without extensive 
testing, whether suffi- 
ciently many operators 
have been added — but 
there is the very real 
problem of making sure 
that they have been 
specified clearly." 
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into account that it may not 
get completely clarified until 
after the standard is adopted. 
At that point, an official "re- 
quest for interpretation" can 
be submitted. I'm not totally 
up on my procedure here, 
but the answer is probably 
binding on the standard 
(could someone from the TC 
spell this out in painstaking 
detail for me, please?). Yes, it 
would be better if that never 
had to be done. Better still is 
a plan to handle corrections. 

"It's a bit like a car trip: if 
a wrong turn was taken 
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somewhere, should we 
just say 'It's history, we 
can't change it'; or do we 
do what most sensible 
people do: get back on 
the right road?" 

"I think that it is a truly 
unwise strategy for the 
ANSI team to propose a 
new language and then 
use strong arm tactics to 
get its acceptance rushed 
through. It will do a great 
deal of harm for the sur- 
vival of Forth to accept a 
bad standard — and I don't 
think anyone should re- 
gard it as 'fate' that we 
must do so." 

Indeed. Make up your 
mind How can ANSI "get 
back on the right road" if it is 
charged with codifying ex- 
isting practice (wrong turns)? 
As soon as it does, it takes a 
turn never before taken. As 
far as "rushing," they haven't 
even gotten to the first public 
review yet! What we've seen 
so far is a rather open win- 
dow into what has before 
been a closed process. (It is 
said that those who like sau- 
sages and politics should not 
watch either being made. 
The same could be said for 
standards.) 

— Doug 

From: John Wavrik 

Re: X3J14 Holding Pattern 

Here 

Greg Bailey writes, 

"With all due respect, I 
find myself disappointed 
with Dr. Wavrik's posting 
of 19 Aug. 91 entitled, 
'General Response to E. 
Rather and G. Bailey.' As 
carefully as I read it, I do 
not see that it is germane 
to most of the points in 
my posting of 16 Aug." 

I hope that by now Mr. 
Bailey has had a chance to 
read the more specific re- 
sponse to his Aug. 16 post- 
ing, which I posted a few 
days ago. It does take some 
time for messages to travel 
from UseNet to GEnie — and 
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I think we'd all benefit by 
having a chance to read, 
think about, and make care- 
ful responses. Generally, I 
find that it isn't a good idea 
for me to post an immediate 
response to a controversial 
topic — it seems better to think 
things over and edit my first 
draft. I apologize for the de- 
lay of a day or two in re- 
sponding. 

"I was hoping that Dr. 
Wavrik would admit to 
the existence of tradeoffs 
and to the fact that the 
work of X3J14 has eco- 
nomic implications be- 
yond the performance of 
Forth in popularity con- 
tests." 

Here, as in other places in 
his messages, Mr. Bailey has 
a tendency to put words in 
my mouth which I have never 
spoken (and which corre- 
spond to thoughts I am not 
thinking). There is no 
"popularity contest" involved 
here — just hard, economic 
reality. My living for the past 
ten years, at least, has been 
directly connected with my 
use of Forth as a tool. I intend 
to keep using Forth to make 
my living. My interest in a 
good standard for Forth is 
very definitely connected 
with my livelihood. Accep- 
tance of Forth in universities, 
colleges, and many parts of 
industry will depend on 
whether a good standard — 
guaranteeing both power and 
portability — is produced. 

"Therefore, I ask again. If 
some particular single one 
of Chuck's implementa- 
tions is 'brilliance' and 
'genius,' then what of all 
his others that differed, 
most notably the Novix 
chip (stacks not part of 
addressable memory, 
memory cell-addressed, 
'reducing architectural 
features to the lowest 
common denominator' 
(Chuck has, in my expe- 
rience, always advocated 
assumption of only posi- 
tive divisors in signed di- 
vision), and so oa" 



I did answer comments 
along this line in my specific 
response to Mr. Bailey. In 
sum, Charles Moore is work- 
ing in a special environment. 
His interest is in hardware 
applications, and his work 
does not require portability. 
He can assume only positive 
divisors in addition, for ex- 
ample, because that is all 
that occur in his work. Oth- 
ers of us work in environ- 
ments in which portability is 
very important (and in which 
negative divisors do occur). 

"I submit that Chuck's 
particular genius has al- 
ways lain in his uniquely 
clear insight about the 
simplest solution to the 
most challenging part of 
any problem. I further 
submit that I've never seen 
any evidence that a single 
architecture/implemen- 
tation frozen for all time 
was anywhere on Chuck's 
agenda. Is this 'disso- 
nance' so disturbing to 
Dr. Wavrik that he feels 
he must 'correct' it by 
attributing to Chuck the 
notion that the immuta- 
bility of the architecture is 
more important than the 
solution of problems?" 

Here again, Mr. Bailey 
seems intent on putting 
words in my mouth. I per- 
ceive no dissonance, nor am 
I correcting Charles Moore. I 
agree with Greg Bailey that 
Chuck's gift is coming up 
with good simple solutions 
to problems. Given the na- 
ture of Chuck's work, he 
would want to experiment 
with very low-level changes 
to his systems. Others of us 
are solving very different 
types of problems. 

Suppose the problem is 
to produce a language that is 
tremendously powerful and 
flexible, yet will allow code 
to run correctly on many 
platforms. What would be 
the simplest possible solu- 
tion to that problem? 

I think if you will look 
back at all I have written, you 
will find that I have only (and 
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consistently for the past sev- 
eral years) made the follow- 
ing observation: It could well 
be that the simplest solution 
is to agree on the architecture 
of an abstract machine (per- 
haps, if necessary, making 
separate but overlapping 
standards for a few different 
types of architecture). 

"Dr. Wavrik, I ask that 
you re-read my earlier 
posting, compare it with 
your reply, and see if you 
don't agree with me that 
your posting has frustrat- 
ingly little to do with the 
issues raised." 

No, I think the specific 
reply I gave you addresses 
the issues quite well. The re- 
posting of the "Architecture 
vs. Implementation" paper 
was only intended to eliminate 
some apparent confusion. 

"Forth is not the result of 
slavish pursuit of 'sym- 
metry,' and portable 
power of the sort your 
paper seems to assert is 
essential." 

Again, words are being 
put in my mouth. I said noth- 
ing about symmetry — al- 
though I do think that slavish 
pursuit of simplicity might 
be worth trying. 

"Do you seriously pro- 
pose that your definition 
of power (portable hack- 
ing) be given absolute 
precedence over other 
definitions of power 
(practical usefulness for 
demanding applications, 
for example) that have 
characterized most of the 
dramatic successes of 
Forth that I am aware of?" 

Again, words are being 
put in my mouth. Portable 
hacking is not my definition 
of power. Power, for me, is 
the ability to accomplish dif- 
ficult things without fighting 
the language. Forth is the 
only language I've ever used 
where I feel that I can con- 
ceive of what needs to be 
done, and Forth will allow 
me to do it Most languages 
Forth Dimensions 



(PCYerk Listing Four, continued from page 18.) 





\ Let do-undefined handle things 
do-undefined 



\ Look like literal? 



\ Following code patches interpret. Do it AFTER you've 
\ allocated methods and variable segments 
: patch-interpret 

[ ' ] <interp-patch> 

['] interpret >body 40 + !t 



\ Put interpret back the way it was . 
: unpatch-interpret 

[ ' ] do-undefined 

['] interpret >body 40 + !t 



\ Initialize the system. 

\ One you've included [i.e., loaded] this code, you must 
\ execute "start-objects" before you can begin defining 
\ any objects. When you're done defining and calling all 
\ your objects [i.e., you're about to make an executable], 
\ execute "end-objects". 
: start-objects 

alloc-ivar_seg 

clear-ivar_seg 

alloc-methname_seg 

clear-methname_seg 

1 curr_meth# ! 

patch-interpret 

clear-o&mstacks 

\ Clean things up 
: end-objects 

unpatch-interpret 

ivar_seg @ free 

methname seg @ free 



\ Allocate ivars segment 

\ Allocate method name segment 

\ Start method #'s 
\ Fix interpret 
\ Initialize the stacks 



\ Put interpret back 
\ Ditch ivars segment 
\ Ditch method name segment 



(End listing. Next issue contains code for basic & storage classes, byte &word arrays, strings, & string arrays.) 



require me to fight them to 
shape their rigid features to 
match the problem (and 
sometimes they are so un- 
suitable that I can't realisti- 
cally do the task). 

Power in Forth comes, in 
great measure, from the user's 
ability to understand how 
the system works — and be- 
ing able to harness that un- 
derstanding. 

We are both in agree- 
ment that power has some- 
thing to do with practical 
usefulness for demanding 
applications — my demand- 
ing applications as well as 
your demanding applica- 
tions. 

"You may feel, for ex- 
ample, that performance 



is no longer relevant, as 
you have posted" 

Again, words are being 
put in my mouth. What I said 
is that language performance 
is no longer measured en- 
tirely in terms of execution 
speed. 

I regard Forth as a "high 
performance language" in my 
area because it facilitates the 
development and modifica- 
tion of programs. I can still 
get close to the speed of 
compiled code by heavy use 
of assembly language (which 
I do when a system has be- 
come stabilized) — but, really, 
high-level Forth running on 
a microcomputer is no match 
in speed for the output of a 
good C compiler. It would 



be foolish to give up the 
attributes which make Forth 
a high performance language 
(in terms of ease of develop- 
ment, power, flexibility) to 
achieve marginal gains in 
execution speed. 

Hang around a university 
for a while — people don't 
talk about how to write 
clever, tight code these days. 
The problem is writing and 
maintaining large programs 
that do powerful things and 
run correctly. 

John J Wavrik 
jjwavrik@ucsd.edu 
Dept of MathC-012 
University of California, San 
Diego 

La JoUa, CA 92093 



From: Elizabeth Rather 

J. Wavrik writes: 

"Both Greg Bailey's and 
Elizabeth Rather"s com- 
ments illustrate the fact 
that there are also people 
in the Forth community 
for whom reusability of 
code is not important — 
?nd who alter their sys- 
tems down to the lowest 
level for each new appli- 
cation." 

John, you're seriously 
distorting the point of Greg's 
and my remarks. We are 
challenging your continuing 
assertion that there is such a 
thing as "traditional" Forth 
from which the world has 
been deviating and which 
ANS Forth is deprecating. 
Our discussion of deviations 
from the earliest days to the 
present is intended to point 
out that there has never been 
such a golden age, and that 
your nostalgia for it is, there- 
fore, inappropriate. 

Greg and I and the entire 
committee are extremely 
concerned with portability 
of application code, as well 
as "programmer portability" 
(the ability of programmers 
to move from one system to 
another, preserving both 
sanity and competence 
without massive new learning 
curves). Why else do you think 
we have invested so heavily 
in the standards effort? 

We hope and believe that 
the steps we are taking will 
improve Forth in both these 
respects. 

"Production of code has 
become an extremely 
expensive affair — I think 
it is more typical these 
days to find people who 
can't afford to throw away 
the kind of time and effort 
needed just for a mar- 
ginal gain in execution 
speed — and I think you 
can find as many of them 
in industry as in 
academia." 

Once again, you are mis- 
taken if you think we dis- 
agree. Our objective in de- 
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ACM SIGForth '92 Forth Language Workshop 

March 5-7, Kansas City, Missouri 

In conjunction with the ACM Computer Science Conference, ACM SIGCSE Computer 
Science Education Conference and ACM SIGAPP Symposium on Applied Computing 

Charles Moore 

the inventor of Forth, speaks on his creation 

Other sessions include: 
A Crash Course in Forth 
Software Project Management 
Panel: "From the Classroom to the Real World" 
Panel: "Comments on dpANS Forth" 
and many more... 

Some of the speakers include Lawrence Forsley of the Forth Institute, Richard 
Haskell of Oakland University, Mike Wong of IBM, Paul Snow of Software 
Construction Company, Frank DiMeo of Villanova University, and Dan Yanoff 
of Keithly Asyst. 
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requested by February 1 5 with the final paper at the conference. 

Special Tutorials 

on Wednesday March 4 

"ShBoom: Damn Fast and Dirt Cheap" 

100+ Mhz stack-based RISC Microprocessor 

"Sun Microsystems: Open Boot" 

The coming standard in portable Forth based firmware 

Reg fees for the workshop are $150/$ 170 (before/after 1/31) for ACM or SIGForth members; 
$190/$210 for Non-Members; $50 for students and $75 for One-Day Only reg (before or after 
1/31). Reg fees for the Special Tutorials are each $50 with the workshop and $60 without. 
Discount hotel rooms at $48 & up per room (up to 4 guests) available before 1/31 by mail only. To 
register or for hotel/room sharing info contact Dr. Leonard Morgenstern, 304 Rheem Blvd., Moraga, 
CA 94556, (510) 376-5241. Payment accepted by check, Visa, MasterCard or American Express. 




Hosted By: 

Digalog 

Shaw Laboratories 
Nanotronics Inc. 
Keithley Asyst 



For paper submission 
information contact: 

Program Chair 
Dr. Paul Frenger 
P.O. Box 820506 
Houston, TX 77282-0506 
(713) 589-9040 
GEnie: P. FRENGER 



To assist in conference organization 
or for special presentations contact: 

Conference Chair 
George Shaw 

Shaw Laboratories Limited 
PO Box 3471 
Hay ward, CA 94540-3471 
(510) 276-5953, 276-6050 fax 
GEnie: G.SHAW1 Compuserve: 70413,2005 
email : george_shaw@ mts . cc . way ne . edu 



Sponsored by the ACM Special Interest Group on Forth 
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scribing Forth behaviorally 
rather than by constraining 
implementation choices is to 
permit implementors to pro- 
vide an internally optimized 
(and hence fast) system 
whose surface, as presented 
to the application program, 
offers a very high degree of 
portability due to its con- 
formance to rigorously de- 
fined behaviors. 

"A major factor, however, 
is that people who do not 
need portability also do 
not need a standard." 

How do you reconcile 
this with your continuing 
assertions that the members 
of the TC don't care about 
portability? Do you contend 
that these people have spent 
tens of thousands of dollars 
and a lot of their billable 
hours over a period of years 
to do something they don't 
need or want' 

The disagreement be- 
tween you and the commit- 
tee is not over who wants 
portability, but how port- 
ability is achieved We be- 
lieve it can most usefully be 
achieved by defining the 
behavior of Forth words, and 
you'd prefer to see their 
implementation standard- 
ized. This is a simple dis- 
agreement, which is okay, 
but the discussion will be 
advanced most usefully if 
you direct your comments to 
that rather than spurious as- 
sertions about mythical tra- 
ditions and the motives of 
the TC members. 

"Simplicity, comprehen- 
sibility, being supplied 
with source code, ability 
to reproduce the system 
are among the things I 
lump under the heading 
'glass box.' If anyone un- 
dertakes to write a stan- 
dard for Forth, these are 
exactly the qualities which 
need to be made por- 
table- 
Simplicity and compre- 

hensibility sound great. No 

argument. 

(GEnie continued on page 28.) 
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Object-Oriented 
Forth 

Roger Bicknell 

New Westminster, British Columbia, Canada 



/n the beginning, there was 
programming. Now, the 
programming was form- 
less and unstructured — 
darkness was over the sur- 
face of the design problem. 

Then came structured 
programming^ — a disciplined 
coding style and a logical 
analysis technique which 
emphasized the nature of 
the coupling between code 
modules and the design 
reasons behind the creation 
of the code modules. Creat- 
ing a routine out of code that 
just happened to be per- 
formed at the same time 
(temporal cohesion) was out 
Creating one routine out of 
code that did a couple of 
closely related things (logi- 
cal cohesion) was out — it 
necessitated passing control 
flags between routines (called 
control coupling, oddly 
enough). There was (once 
again?) the dawning realiza- 



tion that a routine should do 
one thing and only one thing 
(and do it well). However, 
there was more to be discov- 
ered. 

If a careful study of pro- 
cedures proved beneficial, 
then what about a close look 
at the nature and form of the 
data being operated upon 
by those newly-structured 
routines? Thus, someone 
coined the phrase object 
oriented, probably in con- 
trast to the prevailing proce- 
dure-oriented programming 
of the time. 

Enter Analysis of Data 

Data can be kept in atomic 
types like variables, con- 
stants, and literals; or in 
molecular groupings, such 
as named records and in- 
dexed arrays. Many early 
computer languages pro- 
vided a small selection of 
atomic data types and ex- 



two float-type variables called 
REAL and IMAGINARY) that 
data abstraction is important. 
A procedure's code is neces- 
sarily specific aboutwhattype 
of data it operates upon. The 
code of + (plus) assumes an 
integer data type, and F+ (f- 
plus) assumes a floating-point 
data type. These cannot be 
swapped (or even duped — 
else your employment may 
be over). Thus, it only makes 
sense to group the definition 
of a data type with each and 
every procedure that will 
operate upon it — making for 
easier maintenance. When a 
data type's definition and its 
associated procedures are 
grouped into one module, 
further de-coupling between 
modules can be realized. For 
example, a stack can be 
implemented using an in- 
dexed array, or a buffer and 
an offset. Allowing any other 
module to know the imple- 
mentation details is not nec- 



yourself, but you should 
protect your code from what 
those other crazy, reckless, 
undisciplined hacks might 
do. 

It is possible to de-couple 
to the extent of not even 
allowing direct reference to 
a data type's routines. In- 
stead, a message is sent over 
to that module asking for a 
procedure to be enacted. 
Thus, even the data type's 
procedures could be modi- 
fied (which might be neces- 
sary if the details of the data 
change), and still it would 
not affect any other module. 
The intent here is to provide 
robust code by limiting side 
effects of changes, and to 
provide reusable code by 
de-coupling it from as much 
as possible. 

The intent of object-ori- 
ented programming is to 
extend the ideas of struc- 
tured programming to in- 
clude techniques dealing 
with data which enhance 
reliability and which mini- 
mize the maintenance of a 
software project by reducing 
the amount of modifications 
necessitated by a change. 

Glossary 

In the object-oriented 
vernacular, a data structure 
is called an object or an in- 
stance of a class. The class 
contains the information 
necessary to construct an 
instance, as well as all the 
routines that operate on its 
data type. The internal ob- 
jects that make up an in- 
stance (like fields within a 
record) are called instance 
variables. An object is sent a 
message, which specifies 
what to do, but not how to 
do it. The object then finds 
the method, the word that 
performs the correct action; 
this is called binding the 
message to the object. There 
are two forms: earlybinding 
and late (or dynamic) bind- 
ing. Early binding is done at 
compile time and dynamic 
binding is done at run time. 
The ability of one class to 
I gain access to another class's 
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Information hiding is the back- 
bone of code security, reliable 
re-entrancy, and data abstraction 



Roger Bicknell is an electrical engi- 
neer who has programmed in Forth as 
a hobby since 1982. He enjoys the 
simplicity and interactivity of the lan- 
guage, and uses it to experiment with 
language design. He says, "Some 
people gamble, I program... Yes, I 
know it's 4:00 a.m., but I've just got to 
tweak this one last word..." Roger 
welcomes feedback at 315 Devoy 
Street, New Westminster, BC, Canada 
V3L 4E8 or at R.BICKNELL2 on GEnie. 
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pected you to use records, 
for example, to simulate any 
different types of data you 
might fancy. The ability to 
abstract data, or to create a 
new data type, is an essential 
feature of an object-oriented 
language implementation. 

But it is not simply for the 
p pettiness of being able to 
refer to a new data type like 
COMPLEX (say, made up of 



essary and could allow di- 
rect access to elements within 
the stack structure. This di- 
rect access is a potential 
problem for the future, if 
ever the implementation of 
stack structure is changed. 
"What they don't know can't 
hurt you." Of course, it is 
important to keep in mind 
that considerations like 
maintenance are far more 
complex and important for a 
large multi-programmer 
project than for a lone-wolf, 
one-nighter program. You 
needn't hide anything from 



23 



Figure One. Extending common Forth to OOF. 



\ oofinitl.fth 910808 rwb 
only forth also definitions 

4 constant cell \ cell is #bytes in stack width 



cell+ 
cell- 
cells 

struct : 



: field 
create 

over 
does> 

6 + ; 



cell + 
cell - 
cell * 



\ ( — offset ) 

\ ( offset /field — offset" ) 

v 

\ ( 'struct pfa — 'field ) 



/struct \ ( /struct — ) 

constant ; 



cr . ( oof initl loaded ) cr 



910729 rwb 



methods is called inherit- 
ance 

Defining an 
Object-Oriented 
Language 

An object-oriented pro- 
gramming language can be 
described as having at least 
four features: data abstrac- 
tion, information hiding, dy- 
namic binding, and inherit- 
ance. 

Data abstraction is the 
ability to create new data 
types. Of course, common 
Forth already has this. The 
CREATE DOES> team is all 
that is required to invent any 
new data type. For example, 
while standard Forth does 
notspecify array-type data, it 
is a simple task to implement 
such. 

Information hiding is the 
backbone behind code se- 
curity, reliable re-entrancy, 
and data abstraction. Infor- 
mation hiding is necessary in 
order to provide more than 
one context in which to in- 
terpret a name. Local vari- 
ables are an example of in- 
formation hiding, because 
they are unavailable to any 
routines other than the one 
in which they are defined Of 
course, one way to hide 
things in Forth is to put them 
into a separate vocabulary. 
The most obvious reason to 
hide a word in Forth is to be 
able to have more than one 
word with the same name, 
but the concept of informa- 
tion hiding goes a little deeper 
than that. One important tool 
in providing code security 
and reducing interdepen- 
dencies between software 
modules is hiding details of 
implementation. As in the 
example given above, 
whether a stack uses an off- 
set to point into a buffer or 
uses an index into an array 
should not be known or 
exploited by other software 
modules — because if this 
implementation should ever 
change, the exploitive code 
will probably break. Thus, 
information hiding is required 
if one is to provide reliable, 



modifiable code modules. 

Dynamic binding is sim- 
ply the ability to decide upon 
the appropriate method of 
implementing an action at 
nan time rather than at com- 
pile time. This can become 
important when an object's 
class is unknown at compile 
time. This feature has been 
exploited in the definitions 
of PUSH and POP in the 
STACK class code. (See Fig- 
ure Eight, page 30.) Also, a 
stack can be made out of any 
new class of object, and PUSH 
cannot know ahead of time 
the new method's CFA for 
storing the object in the stack. 
Dynamic binding is not al- 
ways necessary, but when it 
is needed, it is indispens- 
able. 

If a new object class is 
very similar to an existing 
class, it may be economical 
for the new class to use some 
of the other's methods, rather 
than rewriting them. This is 
the concept of inheritance — 
allowing a newly defined 
class to inherit some (or all) 
of the methods of an existing 
class. Inheritance allows the 
creation of a new class by 
merely defining the differ- 



File-loading sequenc e. 

\ oof.fth 

: task ; 

fload oofinitl.fth 
fload oof class. fth 
fload oofmssag. fth 
fload oofobjec.fth 
fload oof prima . fth 
fload oof cmplx. fth 
fload oof array. fth 
fload oofstac2.fth 

cr . ( oof loaded ) cr 



ence between the new class 
and a previously defined 
class — thus, a lot of code can 
be reused and time saved 

Commenting Style 

I should first comment on 
my commenting and nam- 
ing style. Consider the com- 
ment for the word CLASS : 
in Figure Two. The <name> 
token appearing before the 
stack comment refers to the 
input stream argument that 
CLASS : requires. Also, I like 
to preface a stack comment 
entry with ' (tick), / (for- 
ward-slash), or A (caret). I use 



tick to mean "address of," 
forward-slash to mean "size 
of," and caret to mean "con- 
tains the address of." Thus 
1 /body in the stack com- 
ment means "the address of 
the size of body." Also note 
thatl like to preface STRUCT : 
fields with + (plus). I just do. 
Forgive me. 

Code Description 

Figure One defines some 
words, additions to common 
Forth, that are used in the 
definition of object-oriented 
Forth (OOF). CELL is set to 
the width of Forth's stack — 
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Figure Two. Object class words. 



\ oof class. fth 910729 rwb 

only forth also definitions 
#vocs cells constant /context 
struct : 



♦threads cells : field +threads 



/ context 
cell 



: field +context 
: field +/body 



; struct /class 



: >context \ ( 'class — ) MACRO to select object's context. 
+context context /context cmove / 

: class : \ <name> ( — ' /body offset ) 

vocabulary 

last @ name> >body >user \ ( — 'body ) 

/context cell+ ualloc drop \ allocate space for 

\ rest of body 
( 'body ) dup context ! \ setup class to be 

\ both context . . 

context over +context /context 

\ { — 'body 'cxt 'c.cxt /cxt ) 
cmove definitions \ ( — 'body ) ..and current vocabs . 
+/body dup off \ ( — '/body offset ) 
does> ( pfa — ) 
>user >context ; 

: END \ ( — ) 

only forth also definitions ; 

: /class \ ( '/body offset — ) 

END swap ! ; 

: METHODS definitions ; 

cr .( oof class. fth loaded ) cr 



my Forthmacs (by Mitch Bra- 
dley) for the Atari ST is a 32- 
bit Forth, so my CELL is set 
to four bytes. Adjust yours 
accordingly. A simple meth- 
od for grouping data into 
named records is provided 
by the three words STRUCT : , 
: FIELD, and / STRUCT. 

Common Forth contains 
the seeds of an object-ori- 
ented language. CREATE 
DOES> provides the ability 
to abstract data and create 
new data types. Vocabular- 
ies can provide privacy, as 
well as inheritance. Thus, 
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only ten new words need be 
used to program in OOF: 
CLASS:, /CLASS, IN- 
HERIT, METHODS, END, 
MESSAGE, OBJECT, OB- 
JECTS, :VAR, and :VARS. 

Figure Two provides 
definitions of object class 
words. I have implemented 
a CLASS as a hybrid of 
STRUCT: and VOCABU- 
LARY — which reflects the 
twofold nature of a class: to 
provide the internal data 
structure of its type, and to 
house the data's routines. 
See Figure Seven (page 29) 
for a good example of how 



these words are used. (In 
Forthmacs, the parameter 
field of a vocabulary is kept 
in the user area. So, while the 
general idea is to build a 
vocabulary with two extra 
fields — the +contextfieldand 
the +/body field — these must 
be allocated in the user area 
for Forthmacs.) 

MESSAGE is defined in 
Figure Three. A message 
merely records its name as a 
string within its body, and 
then tries to find it in the 
context vocabulary (CLASS) 
at run time. (This is an ex- 
ample of late binding.) Note 
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that all messages are pref- 
aced with a < (less-than) 
character. This is done so 
that the message and the 
method will not be confused. 
The < is stripped off before 
being compiled within the 
message with the SWAP 1+ 
SWAP 1- code. 

Figure Four contains 
words which construct in- 
stance OBJECTS and in- 
stance VARiables. An in- 
stance contains two fields: its 
class pointer and its body. 
An instance OBJECT'S body 
contains its instance variables. 
An instance VARiable's body 
contains its offset within its 
parent OBJECT. 

Figure Five (pg. 28) con- 
tains the initial bootstrapped 
object class, called PRIMARY. 
I decided that PRIMARY 
methods should just go in 
the FORTH vocabulary, so that 
PRIMARY would not have to 
be INHERITed by each class; 
thus, the phrase PRIMARY 
METHODS has been com- 
mented out. The only real 
need for a PRIMARY class is 
for indirect reference to the 
object on top of the stack. 
This data must be a declared 
class. PRIMARY is declared 
just for this situation. Other 
than that, its "object-ness" 
may be ignored and it can be 
treated just like a Forth vari- 
able or structure field. 

Figure Six (page 28) is a 
simple example of building 
new classes. Note that the 
methods' code is very Forth- 
ish: the implicit stack opera- 
tors (DUP, SWAP, TUCK, etc.) 
are still needed, parameters 
are still passed on the stack, 
and RPN syntax is still used — 
thus, OOF blends well with 
common Forth. It is not nec- 
essary for 2 COMPLEX to ex- 
plicitly INHERIT from the 
COMPLEX class in order for 
the methods (like 6 0) to pass 
the <@@ message along. In 
this case, the instance vari- 
able X will accept the <@@ 
message and interpret it cor- 
rectly. Inheritance becomes 
an issue when a class that is 
a specialization of another 
class, wishes to use some of 
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Figure Three. Defining MESSAGE. 



\ oofmssag.fth 910729 rwb 

: >in@ ( — ) \ macro to save input stream pointer, 

in-file @ ftell ; 

: >in! ( — ) \ macro to set input stream pointer, 

in-file @ fseek ; 

: MESSAGE \ <name> ( — ) 

>in@ \ remember input stream location, 

create \ create message 

>in! \ put input stream pointer back, 

bl word count \ grab <name> and compile string in 

swap 1+ swap 1- ", \ pfa of message. 
does> ( pfa — ? ) 

find 
if 

execute \ effect method of action. 

else 

abort" method unknown" 

then 



cr .( oofmssag.fth loaded ) cr 



the other class's methods. 
For example, if one had both 
AUTOMOBILE class and 
CHEVY class, there may be 
AUTOMOBILE methods that 
are applicable to the CHEVY 
class objects. By simply stat- 
ing AUTOMOBILE INHERIT 
before defining CHEVY class, 
it inherits all the methods of 
AUTOMOBILE. I used this 
feature to provide STACK 
objects with the <LENGTH 
operator, by inheriting it from 
the ARRAY class. 

Figure Seven (page 29) is 
an example of defining an 
ARRAY class of objects. The 
#EL instance variable con- 
tains the number of elements 
in the array. The "EL-CLASS 
variable points to the class of 
the array's elements. Con- 
sider the INDEX method the 
last thing that must be done, 
after deriving the address of 
the indexed element within 
the array, is to switch the 
class context to that of the 
elements so subsequent 
messages will be bound to 
the correct instance type (and, 
thus, the correct method will 
be executed). The words 
OBJECTS and :VARS in 
Figure Four assume that the 
first two instance variables 
within a group-type object 
(like ARRAYS, STACKS, 
MATRICES, QUEUES, etc) will 
be #EL and "EL-CLASS, 
respectively. 

Figure Eight (page 30) 
gives an example of IN- 
HERITing a class — as STACK 
is a specialization (and 
superset) of ARRAY class. 
Note that the class context 
must be switched to that of 
the stack's elements just be- 
fore the message is sent to 
fetch or store the element 
object in bothPUSH and POP. 

One kludge I wanted to 
avoid in defining grouped 
objects (like ARRAYS and 
STACKs) was the need to 
predetermine the size of the 
body in the class definition. 
This would either cause all 
the ARRAYS (or STACKs) to 
have the same number of 
elements, or else necessitate 
a new defining word for cre- 



ating objects for each new 
group-type class. Consider 
the following instantiation of 
a COMPLEX STACK. 

STACK OBJECT FRED 
23 COMPLEX OBJECTS 

Thus, FRED is defined as 
the object at the head of the 
group of elements, with the 
defining word OBJECT. Then 
23 complex-type objects 
were allotted. OBJECTS is 
capable of patching the pre- 
viously created word (in this 
case, FRED) with the num- 
ber of elements allotted into 
FRED's #EL instance vari- 
able. 

The benefit of an object- 
oriented implementation's 
security can be seen by com- 
paring the code of Figure 
Eight with that of Figure Nine 
(page 31). Both are imple- 
mentations of stack-type data, 
but are radically different. 
Note that code using STACK 
would not break if STACK 
were changed — due to be- 
ing forced to use only pro- 
cedures within the STACK 
class's code-definition mod- 
ule. 



Conclusion 

If an object-oriented pro- 
gramming language is de- 
fined by the characteristics 
of data abstraction, informa- 
tion hiding, dynamic bind- 
ing, and inheritance, only a 
little needs to be added to 
Forth to make itso. In keeping 
with an RPN syntax, the 
process ofbinding a message 
is shared between the object 
and the message words. It 
may appear that this respon- 
sibility could have been 
wholly shifted to the mes- 
sage word, but only because 
this is a late-binding example. 
Because late binding has an 
associated run-time penalty 
(finding the correct method 
to execute), early binding is 
usually used except when 
late binding is required. It 
would take about two more 
words, and about five min- 
utes of coding, to convert the 
given code to early binding 
(really!). This will be left as 
an exercise to the reader. 
(Oh! I've always wanted to 
say that!) Maybe I will up- 
date the code in an upcom- 
ing article. . . Also, one could 



optimize the code associ- 
ated with the first instance 
variable reference. Because 
it has an offset of zero within 
the parent object, it is waste- 
ful at run time to add the 
offset. 

Object-oriented Forth, as 
presented, is upwardly com- 
patible with common Forth 
(Forth-83, specifically); thus, 
they can be intermixed at 
will. Programming in OOF 
promotes grouping all of a 
data class's routines, just be- 
low the declaration of the 
inner layout of the class. Also, 
it allows one to focus on 
objects and actions without 
constant regard to internal 
implementation details (one 
definition of PUSH works for 
any kind of STACK). 

An object orientation is 
simply the coding disciplines 
specific to the expression of 
data, and which are comple- 
mentary to those for proce- 
dures. The intent is to reduce 
maintenance by minimizing 
modifications caused by a 
change, and to increase pro- 
ductivity by enhancing reus- 
ability of existing code. 
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Figure Four. Words to create objects and instance variables. 



\ oofobjec.fth 



910730 rwb 



: +objects \ ( 'body — 'objects ) MACRO 

dup cell- @ \ ( — 'body 'el-class ) 

+/body @ + ; 

: /body \ ( — /body ) 

context @ +/body @ ; 

: do-object \ ( /body — ) 

allot 
does> 

dup @ >context \ select object's context. 

cell+ \ ( — 'body ) 

t 

: object \ <name> ( — ) Create instance of class, 

create context @ , /body do-object ; 

: objects \ ( n — ) Create n instances of class, 

/body over \ ( — n /body n ) 

last @ name> >body cell+ \ ( — n /body n 'body ) 
context 6 over cell+ \ ( — n /body n '#el 'elclass "elclass ) 
! ! \ ( — n /body ) 

* do-object ; 

: do-var \ ( offset /body — offset' ) 

over , + 
does> ( pfa — 'body ) 
dup @ >context 

cell+ @ + \ ( — 'var ) 

: :var \ <name> ( offset — offset' ) Create instance variable, 

create context @ , /body do-var ; 

: :vars \ ( offset n — offset" ) Create n instance variables, 

/body over \ ( — offset n /body n ) 

last @ name> >body cell+ \ ( — offset n /body n 'body ) 
context @ over cell+ \ ( — offset n /body n ' #el 'elclas "elclass ) 
! ! \ ( — offset n /body ) 

* do-var ; 

cr .( oofobjec.fth loaded ) cr 
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MAKE YOUR SMALL COMPUTER 

THINK BIG 

(We've been doing it sines 1977 for IBM PC. XT. AT. PS2, 
and TRS-BO models 1.3 4 & 4P J 

FOR THE OFFICE — Simplify and speed your work 
with our outstanding won) processing, database handlers, 
and general ledger software They are easy to use, powerful, 
with executive-look print-outs, reasonable site license costs 
and comfortable, reliable support Ralph K Andnsl, author/ 
historian says ''FORTHWRITE lets me concentrate on my 
manuscript, not the computer" Stewart Johnson. Boston 
Ma.'vjO,. ,.i,s A»Lr>'DATAHANDLEn-PLUSr>uiiwl! 
the best we ve seen ' 

MMSFORTH System Dk* from $ 179 95 

Moduujr-^ddng — Integrate with System Disk only what 
you need- 

FORTHWRITE -Vvbrdprocessor $9995 
MTAHANOLER- Database $5995 
MTAHANDLER-PLUS - Database $99 95 

FORTHCOM- for Communications $49 95 

GENERAL LEDGER - Accounting System $25000 

MMF0R7H 

MILLER MICROCOMPUTER SERVICES 

S1 Lake Shore Road, Natick, MA 01780 
(508/653-6136, 9 am - 9 pm) 



FOR PROGRAMMERS — Build programs FASTER 
and SMALLER with our ' Intelligent" MMSFORTH System and 
applications modules, plus the famous MMSFORTH continu- 
ing support Most modules include source code Ferren 
Maclntyre, oceanographer, says. "Forth is the language that 
microcomputers were invented to run " 

SOFTWARE MANUFACTURERS — EfV entwti 
ware tools save time and money MMSFORTH's flexibility, 
compactness and speed have resulted in better products in 
less time for a wide range of software developers including 
Ashton-Tate. Excalibur Technologies. Lindbergh Systems, 
Lockheed Missile and Space Division, and NASA-Godderd 

MMSFORTH VZ4 System Dak tun J '"1 

Needs only 24K RAM compared to 100K for BASIC. C, 
Pascal and others Convert your computer into a Forth virtual 
machine with sophisticated Forth editor and related tools This 
can result in 4 to 10 times greater productivity 



Integrate with System Disk only what 
you need 

EXPERT-2 I »;*"1".svir ijevelopment $69.95 
FORTHCOM - Flexible data transfer $4995 
UTILITIES Graphics, 8087 support and other facilities 

and a little more! 

THIRTY-DAY FREE OFFER - Free MMSFORTH 
GAMES DISK * --i>- S'O * Ih purchase of MMSFORTH 
.PER, OTHELLO, BREAK- 
FORTH and others. 

Caff for free brochure, technical Into or pricing eMatt. 
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On-Line 
Resource 

Updates 

Two out-of-date items 
mistakenly crept into last 
issue's "reSource Listings." 
These are the Wetware Forth 
conference (under Unix 
BBS's) and the Cave (under 
non-Forth-specific BBS's with 
extensive Forth libraries). 
Please disregard both. 

In France, the Forth BBS 
JEDI has ceased operating. 
Try Serveur Forth, which 
claims news, services for new 
programmers, Forth teaching 
material, and a file library. It 
supports up to 19200 baud, 
depending on access method 
(for full details about high- 
speed, Minitel, or alternate- 
carrier access, contact sysop 
Marc Petremann, REM Corp., 
17 rue de la Lancette, F-75012 
Paris, France). From within 
France via modem, call the 
following. (From Germany, 
add the telephone prefix 00 
33. From other countries, use 
the prefix 33 ) 

(1) 4108 1175 

300 baud (8N1) or 

1200/75 E71 

OK 

(1) 41 08 11 11 

1200 to 9600 baud (8N1) 

The Programmer's Cor- 
ner BBS in Maryland has a 
Forth message area and a 
Forth file area. Call 401-596- 
1180 or 401-995-3744. 

Additional non-Forth- 
specific BBS's with extensive 
Forth libraries: 

• PDS*SIG 
San Jose, CA 
408-270-0250 
SprintNet node casjo 
StarLink node 6450 

• Programmer's Corner 
Baltimore/Columbia, MD 
301-596-1180 or 
301-995-3744 
SprintNet node dcwas 
StarLink node 2262 

(Note: PC-Pursuit is now 
SprintNet) 
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Figure Five. The initial, "bootstrapped" class. 
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\ oof prima. fth 

MESSAGE <@@ 
MESSAGE <! ! 
MESSAGE <?? 
MESSAGE <init 



Class: PRIMARY 

cell+ \ bootstrap size of class 

/class 



\ PRIMARY METHODS 
: @@ 

; 



init 



off ; 



\ ( 'body — primary ) 

\ ( primary 'body — ) 

\ ( 'body — ) 

\ ( 'body — ) 



END 



cr . ( oof prima. fth loaded ) cr 



Figure Six. Building new classes. 




\ oofcmplx.fth 


910728 rwb 


only forth also definitions 




\ MESSAGE <@@ 






\ MESSAGE <! ! 






\ MESSAGE <?? 






\ MESSAGE <init 






class : 


COMPLEX 








PRIMARY :var 


real 






PRIMARY :var 


imag 




; class 








COMPLEX METHODS 






: @@ 


\ ( 


'body — 


real imag ) 




dup real @ 


swap imag @ ; 


: ! ! 


\ ( 


real imag 'body — ) 




tuck imag ! 


real ! 


/ 


: ?? 


\ ( 


'body — 


■ ) 




dup imag ? 


real ? ; 




: init 


\ ( 


'body — 


■ ) 




dup imag off 


real off ; 


END 








class : 


2 COMPLEX 








COMPLEX :var 


X 






COMPLEX :var 


y 




/class 








2 COMPLEX METHODS 












(Figure continues.) 
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(GEnie from page 22.) 

Regarding "being sup- 
plied with source code," two 
comments: 

(a) Forth, Inc. supplies 
complete source code under 
license with all polyFORTHs, 
along with the ability to re- 
produce the system, as we 
believe these are important 
entitlements to those of our 
customers who do want to 
optimize their applications 
in the knowledge that they 
will be fairly transportable 
across polyFORTHs on other 
platforms, but harder to port 
to other Forths. Making this 
choice is their prerogative. 

However, as you your- 
self point out, there are other 
people for whom the need 
for portability is paramount. 
The standard, also as you 
point out, is for those people. 
If the TC mandates that all 
conforming implementations 
not only follow a particular 
model but supply source and 
regeneration capability, the 
result will be y^conforming 
implementations, and me- 
diocre performance on those 
that do conform. It's hard to 
see how this benefits any- 
one. 

This is why the TC be- 
lieves the better way to facili- 
tate portability is by stan- 
dardizing behavior. 

(b) The reality of the 
marketplace is that most of 
Forth, Inc.'s competitors do 
not supply source and re- 
generation capability, and 
they are nonetheless suc- 
cessful in their respective 
markets. This supports the 
conclusion that there are very 
many Forth programmers 
who don't find these things 
essential to their work. 

In summary, I personally 
agree with you as to the 
value of source and regen- 
eration capability, but em- 
phatically do not agree that 
they should be mandated in 
a standard. 

"Since when are the two 
previous standards for 
Forth 'some particular 
model? 

Greg was only trying des- 
Forth Dimensions 



perately to understand what 
on earth you do mean in 
invoking "traditional Forth," 
as you keep doing. 

"I use 'Forth' to refer to 
the language as described 
in the books cited most 
often as references: 
Starting Forth and 
Thinking Forth by Leo 
Brodie, and Forth- A Text 
and Reference by Kelly 
and Spies." 

At last, a workable defini- 
tion! However, these fine 
books all make it very clear 
that, although they discuss 
such things as dictionary 
structure for pedagogic pur- 
poses, implementations do 
vary. Primarily, they define 
Forth behaviorally, just as 
ANS Forth does. I quote from 
Kelly & Spies (pg. 305-6): 

"The Forth standards 
wisely make no attempt 
to define how the lan- 
guage works internally. 
The point of the stan- 
dards is to promote a 
functional compatibility of 
programs, not to stifle 
original ways of adapting 
Forth to new hardware." 

Couldn't have said it bet- 
ter myself. 

"Several of the languages 
I have used... are de- 
scribed as 'functional' 
languages. . . Each of these 
languages is described in 
terms of a set of opera- 
tors. In each case, how- 
ever, the operators act on 
a specific data type or 
types. . . It is meaningless 
to have operators that do 
not operate on anything! 

"The ANSI Team has ap- 
parently not only invented 
a new language, but also 
a new concept in com- 
puter science: a language 
that manipulates data 
structures in a functional 
way, but does not allow 
us to know what the data 
structures are. Sure 
doesn't sound like a good 
idea, does it' Certainly 

Forth Dimensions 



(Figure Six, continued.) 



: @@ 




\ 


( 'body — x y ) 


dup 


>r 


X 


<@@ 




r> 


y 


<@@ ; 


• it 




\ 


( x y 'body — ) 


dup 


>r 


y 


< ! ! 




r> 


X 


< ! ! ; 


: ?? 




\ 


( 'body — ) 


uup 


>r 


y 


<?? 




r> 


X 


<?? ; 


: init 




\ 


( 'body — ) 


dup 


>r 


y 


<init 




r> 


X 


<init ; 


END 








\ Example : 


2COMPLEX OBJECT 2understand? 


\ . . oh gosh NO 


1 


:") 


cr . ( oofcmplx. 


fth loaded ) cr 



Figure Seven. Defining an array class. 




\ oof array. fth 910723 rwb 




MESSAGE <index 




MESSAGE <length 




class: ARRAY 




PRIMARY :var #el 




PRIMARY :var A el-class 




; class 




ARRAY METHODS 




: '/el-body \ ( 'body — '/el-body ) MACRO 


^el-class @ +/body ; 




: index \ ( i 'body — 


objects [i] ) 


tuck A el-class @ dup >r 


\ ( — 'body i 'el-class ) 


+/body @ * 


\ ( — 'body offset ) 


swap +objects + 


\ ( — 'body[i] ) 


r> >context ; 




: length \ ( 'body — n ) 


dup '/el-body @ 




swap #el @ * ; 




END 




cr . ( oof array. fth loaded ) cr 





isn't a tested idea, is it?" 

Can't offhand think of any 
languages that describe how 
their data structures are ar- 
ranged in memory, let alone 
how their code is arranged in 
memory, which is what you 
seem to expect of Forth. ANS 



Forth pays a great deal of 
attention to describing data 
types, at least as clearly as C, 
etc. It also explicitly describes 
(Section 5.4 in BASIS, 3.4 in 
dpANS-2) the regions of 
memory that are address- 
able by a standard program. 
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Most high-level languages 
don't letyou address memory 
at all. C sort of does, via 
'pointers,' but pointers are 
still a lot more abstract than 
Forth's addresses. 

"...an attempt to rescue 
some of the functionality 

January 1992 February 



of classical Forth... And 
Forth did have a viable 
solution, didn't it' And 
the ANSI team is propos- 
ing a language that ignores 
this solution, isn't ft?" 

We'd sure appreciate it if 
you'd share this "viable solu- 
tion" with us, John. And 
please be specific, rather than 
vaguely alluding to "classical 
Forth," so we can consider 
your proposed language for 
incorporation. 

We believe ANS Forth is 
extensible, and would very 
much like to know exactly 
what you feel is compro- 
mised. As you seem to have 
a high regard for precise lan- 
guage, well be grateful if 
you'd offer us some as an 
example. 

Your discussion of 
START : would be helpful, 
except that Mitch has already 
told you that we agreed there 
was a problem with 
BASIS 15's definition and 
fixed it. Well look forward 
to seeing whether you agree 
that it is fixed in dpANS-2. 
There are probably a lot more 
areas in which clarity can be 
improved, and appreciate 
people pointing out other 
specific instances. 

"I think it is a truly unwise 
strategy for the ANSI team 
to propose a new lan- 
guage and then use strong 
arm tactics to get its ac- 
ceptance rushed through." 

We have no intention of 
doing so, and couldn't if we 
did. The public review pro- 
cess is deliberately lengthy, 
in order to ensure as much 
feedback as possible. 

"It will do a great deal of 
harm for the survival of 
Forth to accept a bad 
standard — and I don't 
think anyone should re- 
gard it as fate that we 
must do so." 

We heartily agree. We 
look forward to hearing from 
lots of people in the public 
review process. 



Figure Eight. Code for the stack class. 




\ oof stack. fth 910723 rwb 












\ MESSAGE <@@ 














\ MESSAGE <init 














MESSAGE <push 














MESSAGE <pop 














ARRAY 


also 














class : 


STACK 
















PRIMARY :var #el 
















PRIMARY :var "el-class 
















PRIMARY :var "tos 














; class 
















STACK 


METHODS 














: push 


\ { obj 'body — 


) 














dup "tos @ swap 






\ 


( 




obj 'tos 'body ) 




' /el -body @ negate \ ( 




obj 


■tos 


'body -/body ) 




over "tos \ ( 




obj 


'tos 


'body -/body "tos ) 




+ ! 






\ 


( 




obj 'tos 'body ) 




"el-class @ >context <!! 














: pop 


\ ( 'body — obj ) 














dup "tos >r 






\ 


( 




'body ) 




dup ' /el-body @ >r 






\ 


( 




■body ) 




dup A tos @ 






\ 


( 




'body 'tos ) 




swap "el-class @ >context 


<@@ 


\ 


( 




obj ) 




r> r> +! ; 














: init 


\ ( 'body — ) 
















dup "tos >r 






\ 


( 




■body ) 




dup +objects >r 






\ 


( 




'body ) 




dup ' /el-body @ >r 






\ 


( 




■body ) 




#el @ r> * 






\ 


( 




length ) 




r> + 






\ 


( 




'bos ) 




r> ! ; 














: @@ 


\ ( 'body — obj ) 














dup "tos @ 






\ 


( 




'body 'tos ) 




swap "el-class @ >context 


<ee ; 


\ 


( 




obj ) 


END 
















cr . ( 


oof stack. fth loaded ) cr 















From: Steve Geller 

I used to use Forth, but 
got tired of my boss blaming 
all the software bugs on Forth 
(he's a Fortran and BASIC 
enthusiast). I now write most 
of my software in C and 
assembler. 

The non-portability of 
Forth has annoyed me, be- 
cause I work on a variety of 
environments: PC, Unix, 
VAX, Mac, and some em- 
bedded stuff. The chief an- 
noyance was when a word 
with the same name did dif- 
ferent things depending on 



the implementation. This is 
the main reason for stan- 
dardization, in my view. 

I think much of the 
squabble I read here will 
fade away once a standard is 
clearly defined — and widely 
implemented. I may well take 
another look at Forth when 
ANS Forth appears. I sure do 
like the consistency of C 
implementations; most of the 
problems I've hit were with 
small differences (or just plain 
bugs) in run-time library 
implementations. 

Some argument centers 



on whether ANSForth should 
codify existing practice or 
define a better language. The 
first idea seems rather reac- 
tionary. The present imple- 
mentations are not going to 
disappear when ANS Forth 
appears; there will be a period 
of transition. If the standard 
is well defined, it will be 
accepted in the marketplace 
and everyone will be better 
for it Variant Forths will be 
around forever. There are 
always "extensions" to any 
standard. F83 was full of 
extensions to the '83 stan- 
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Figure Nine. 



\ OOFNEWST . FTH 910818 rwb 

\ message <ee 

\ MESSAGE <init 
MESSAGE <push 
MESSAGE <pop 



ARRAY also 

class : STACK 

PRIMARY :var #el 
PRIMARY :var ^el-class 
PRIMARY :var head 

; class 

STACK METHODS 

: element-context \ ( 'body 

^el-class @ >context ; 



-- ) 



: 'obj \ ( 'body — 'obj ) 

dup +objects swap \ ( 

dup #el @ over head @ \ ( 
- swap ' /el-body @ \ ( 

* + ; 

: full? \ { 'body — f ) 

dup head @ swap #el @ = ; 

: empty? \ ( 'body — f ) 

head @ 0= ; 

: push \ ( obj 'body — ) 

\ check not full 
\ incr head 
\ set element context 
\ store obj 
dup full? not 
if 

1 over head +! 
dup 'obj 
swap element-context 
<! ! 

else 

abort" Stack Full!" 

then ; 

: pop \ ( 'body — obj ) 

\ check not empty 
\ set element context 
\ fetch obj 
\ deer head ptr 
dup empty? not 
if 

dup >r -1 >r 
dup 'obj 
swap element-context 
<@@ 

r> r> head +! 

else 

abort" Stack Empty!" 

then ; 



' objects 
' objects 
' objects 



'body 
'body 
head' 



\ ( — obj 'body ~f ) 
\ ( — obj "body ) 
\ ( — obj 'body ) 



) 

#el head 
el-/body 



\ { — 'body ~f ) 
\ defer til after obj fetch. 

\ ( — obj ) 



(Figure continues.) 
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dard, and became a de facto 
standard itself. 

The question is really 
whether the ANS standard 
will be an attractive proposi- 
tion to users and implement- 
ors. I should think it might 
be, given the background 
and caliber of people work- 
ing on the committee. I am 
going to try to obtain a dpANS 
document whenever it be- 
comes available to the gen- 
eral public. 

From: John Wavrik 
Subject Traditional Forth 

Elizabeth Rather writes, 
"Traditional Forth, for 
example, allows the user 
to know and make use of 
knowledge of what is 
'compiled' (or, more ac- 
curately, assembled) — 
and to exercise total con- 
trol over the process. 

"Hogwash! What on earth 
is this 'traditional Forth,' 
and what did it 'compile 
or assemble? Did it as- 
semble the same thing on 
a 6502 as it did on a PDP- 
11? If so, how did it run' 
And if not, how could the 
user 'know and make use 
of that knowledge in a 
transportable fashion 7 " 

To describe what I call 
traditional Forth, perhaps it 
would be wise to repeat the 
major texts I have used in 
teaching Forth am not go- 
ing back to Kitt Peak Primer 
and the various manuals, 
Forth Dimensions articles, 
etc. that I used to actually 
learn the language — just the 
printed works that I feel de- 
scribe what I am calling tra- 
ditional Forth): 

1. Starting Forth by Leo 
Brodie (published by 
Forth, Inc!!!) 

2. Thinking Forth by Leo 
Brodie 

3. Forth: A Text and Refer- 
ence by Kelly & Spies 

I should also list the sys- 
tems I have used over the 
years, all of which have been 
reasonably consistent with 
the description of Forth given 
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(Figure Nine, continued.) 



: is Is 




\ ( 'body — obj ) 








\ check 


not empty 








\ set element context 








\ fetch 


obj 








dup empty? not 




Dociy i ) 




if 












dup ' obj 










swap element -context 










<@@ 


\ ( - 


- obj ) 




else 












abort" Stack Empty!" 








then ; 








: init 




\ ( 'body -- ) 








head off ; 






END 











in these books: 

MMS-Foith for TRS-80 

Model I (two versions) 
MMS-Foith for IBM-AT 
MVP-Forth for DEC Rainbow 
MVP-Forth for IBM-AT 
MVP-Forth for Apple n 
Kitt Peak VAX-Forth 
F83 for IBM-AT 
Guy Kelly Forth for IBM-AT 

I also use F-PC, which is 
moderately consistent 

I should mention that I 
have found it not too difficult 
to interchange code between 
these systems — so my own 
experience has been with 
Forth as a fairly portable lan- 
guage. 

As for what these systems 
assembled, and how use is 
made of it: 

In each of these systems 
(see also the texts), the body 
of a dictionary entry consists 
generally of a sequence of 
addresses of component 
words. Embedded data is 
preceded by a "handler" 
word. Control flow is 
achieved by the inclusion of 
branching words (only a 
conditional "branch on zero,'' 
traditionally called ? BRANCH 
or BRANCH, and an uncon- 
ditional BRANCH are 
needed) and special words 
to handle the DO ... LOOP 
construct 

This information consti- 
tutes the machine language 
for the abstract processor on 
which all these versions of 
Forth are built As it turns 



out, knowledge of the exact 
addresses is not needed to 
exercise control. Only the 
fact that the components are 
of the form described above 
(together with a few extra 
details about how the pro- 
cessor acts when executing 
the code). 

Let's examine how this 
knowledge is used to solve a 
simple (but somewhat 
amazing) problem.- the intro- 
duction of a new data type 
into the Forth system. Forth 
is remarkable in that new 
data types can be introduced 
seamlessly. One aspect of 
this is the production of ap- 
propriate handlers for a new 
data type. 

Traditional Forth comes 
with only one data type: the 
integer (possibly also double- 
precision integers). The han- 
dler embedded in code for 
the integer data type is tra- 
ditionally called LIT. When 
LIT executes, it puts on the 
stack the integer immediately 
following it in the dictionary 
body, and then it moves the 
instruction pointer past that 
integer. Here is the definition 
that works on all the systems 
mentioned abover 

: LIT 

R> DUP CELL 
+ >R @ ; 

We are using here the fact 
that all of these systems in- 
crement the instruction 
pointer and store it on the 
return stack when a new 



word executes. We can eas- 
ily imitate this guide to skip 
over embedded data of any 
size, and put any informa- 
tion about it on the stack — 
perhaps just the starting ad- 
dress. 

should mention that an 
important aspect of Forth in 
my work is the ability to 
seamlessly integrate into a 
Forth system new and un- 
usual data types — some sys- 
tems have as many as seven 
new types, each with appro- 
priate mechanisms for stor- 
age management, appropri- 
ate handlers, operators, etc.) 

The basic control struc- 
tures are defined in the same 
way in all of these systems. 
For example: 

: IF 

COMPILE ? BRANCH 

HERE , 

; IMMEDIATE 

: THEN 

HERE SWAP ! 
; IMMEDIATE 

(Compiler security has been 
ignored. I believe all the 
above systems use the abso- 
lute address rather than a 
displacement — but the 
change is not a major one.) 

With this information, one 
can produce any conceiv- 
able control structure on any 
of these systems by laying 
down and resolving the ap- 
propriate branch instructions. 
(To be sure, some such 
structures, like the Eaker case 



statement, can be synthe- 
sized using standard control 
constructs — although with 
reduced efficiency.) 

In brief, the user has both 
knowledge of and control 
over what is assembled. The 
standard language provides 
words (like the control flow 
words) that introduce vari- 
ants into the normal succes- 
sion of addresses constitut- 
ing the machine language of 
the abstract machine — but 
access is there for the user to 
do something different In 
effect, the user has as much 
control over the process of 
translating a high-level lan- 
guage into "object code" as 
does the writer of a compiler 
for a conventional language. 
The user has the tools to 
make a high-level language 
look like anything he 
wishes — because he has 
complete control over the 
process of compilation. And 
he can do it portably if he 
uses "traditional Forth." 

This is a remarkable and 
somewhat subversive idea: 
that a user should have power 
normally reserved to spe- 
cialists. I wouldn't dismiss it 
as hogwash if I were you! 

From: John Wavrik 
Re: Disenfranchised 

Mitch Bradley writes, 

"Where Dr. Wavrik has 
been specific rather than 
philosophical (e.g., user- 
defined control struc- 
tures), the committee has 
attempted to deal with 
the issues. It would have 
saved me a lot of time if 
the specific issues had 
been presented in the 
form of proposals; then I 
wouldn't have had to do 
the work of writing the 
proposals." 

In the interest of histori- 
cal accuracy, Mitch Bradley 
had a proposal he wanted to 
submit in this area. He con- 
sulted me and a few other 
people. I gave him my im- 
pression of his proposal, but 
he submitted it anyway. I do 

(GEnie continued on page 38.) 
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Forth is a minimalist lan- 
guage, by which we 
mean that the core of 
the language provides facili- 
ties from which the user/ 
programmer can build his 
own working environment. 
It has also been described as 
a syntax-directed language 
because, if you can define a 
syntax which will best ex- 
press your needs, Forth will 
allow you to create a func- 
tional equivalent suitable for 
programmer use. 

The latest thing in pro- 
gramming tools is the use of 
the object-oriented approach, 
where data and operations 
upon that data are all part of 
the same "object." This is 
often refered to as encapsu- 
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lotion and results in im- 
proved data security, as only 
those operations which have 
been designed to work with 
the object's data structure 
will be executed, and there is 
no direct access to the data 
itself. The user of an object 
need have no knowledge of 
the details of data storage or 
even details of the appli- 
cable methods. He/she just 
needs to know the valid op- 
erations and any parameter- 
passing requirements which 
may be necessary to operate 
upon the object. 

The user also needs to 
know the terminology which 
fits the use of these tech- 
niques. There are several 
variants on the object-ori- 



ented theme, but the follow- 
ing is adequate for our needs. 

A class definition speci- 
fies the data structures 
needed, any initialization, 
and the operations which 
may be performed upon the 
class. 

An instance is a particu- 
lar object of a specific class, 
and has built the data struc- 
tures defined in the class 
definition. 

A method is an operation 
which can be performed 
upon an object 

Inheritance allows the 
user to minimize the addi- 



tional programming neces- 
sary to handle a new varia- 
tion on an object If the 
methods defined for the an- 
cestor object are valid, the 
object will simply obtain them 
via the inheritance chain. If 
there is the need for a different 
definition of a method for a 
new class, that may be in- 
cluded in the new class and 
will only work for the new 
class of object and its 
decendents. This ability is 
called polymorphism. 

Overloading is the ability 
to have more than one defi- 
nition of the same method, 
and ensuring that the correct 
one is applied to a particular 
object 

Forth has the facilities to 
create a very simple but ef- 
fective object-oriented pro- 
gramming environment. The 
following discussion and 
development will not pro- 
duce the fastest object-ori- 
ented implementation in 
Forth, but will introduce the 
direct application of defin- 
ing and compiling words to 
establish an appropriate syn- 
tax. 

The first requirement, 
then, is to propose an appro- 
priate syntax to represent the 
object class. (See Figure One.) 

By analogy with cook- 
ing, one should consider that 
this syntax provides the 
recipe to create new objects 
but that one must use the 
recipe to make an object 
(i.e., create an instance) be- 
fore one can use it 
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This syntax must provide 
the compiler with all the in- 
formation needed to con- 
structthe object The method 
names must be available for 
use by any class definition, 
and so will have to be defined 
before use. 

It will also be necessary 
to provide syntactic delimit- 
ers between the method 
name and the method, and 
also to separate this from the 
following method name. 
These methods may result 
from short in-line definitions 
or may need to access pre- 
defined and hidden method 
definitions. Appropriate de- 
limiter pairs which have been 
selected are: : : and ; ; for 
in-line definitions, M: andM; 
for predefined methods. 

Note for understanding 
the following code 

1. The operations are made 

independent of 16-bit or 
32-bit Forth implementa- 
tions by using the constant 
WS IZE which returns the 
number of bytes assigned 
to storage of an integer 
variable. This technique 
reduces the efficiency of 
definitions but ensures 
portability, which is a 
reasonable compromise. 

2. Hidden methods must be 
passed the address of the 
beginning of data within 
the object itself, and this 
is shown in the stack 
comments as "addr" on 
top of the stack. 

3. The stack comments for 
the methods indicate the 
parameters needed when 
applying the method and/ 
or the results produced 
by the method. 

4. The class must inherit from 
another class or NULL. 

Putting this together for 
an example class which 
consists of a point defined by 
its x,y coordinates and a va- 
riety of useful (and not-so- 
useful) methods, [refer to 
Figure Two]. 

To create an instance of 
this class called PT we sim- 
ply execute: 
10 15 POINT PT 
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To hide complex methods, we 
can set up a new vocabulary. 



This particular example 
has been designed to initial- 
ize the x and y coordinates to 
10 and 15, respectively, so 
the most likely operations to 
follow are similar to those 
given in Figure Three. 

The syntax is, of course, 
typical RPN where the pa- 
rameters are put on the stack 
first, then the message or 
method selector. Finally the 
operation is performed by 
the object itself, which is just 
what object-oriented pro- 
gramming is all about 

Examples of inheritance, 
polymorphism, and over- 
loading can easily be devel- 
oped by extending from a 
Point class to a Rectangle 
class, and further to a Square 
class. To simplify the discus- 
sion, we will use a rectangle 
oriented parallel to the x and 
y axes, which can be defined 
by its two opposite corners: 
upper left (ul) and lower 
right Or). (See Figure Four.) 

Creating the object be- 
comes simply : 
40 18 6 10 RECTANGLE 
RECT 

The rectangle object con- 
tains two points, and it is 
appropriate that the designer 
of the new class can operate 
on these hidden or anony- 
mous objects as if they were 
separate. To obtain the up- 
per left and lower right cor- 
ner values for the rectangle, 
we have used the structure 
GETXY IN PT, giving us ac- 
cess to the point methods 
needed. We could have used 
the GETXYM word from the ' 
(METHODS) vocabulary, 
because it is designed to work 
with a POINT object. This is 
only possible because we 
have not made our Point 
methods totally hidden to 
other classes. If we took ad- 
vantage of the EXCISE facility 
included with UR/FORTH, 
we could not cheat by ac- 
cessing the hidden methods. 

The programmer may 
want to use a particular class 
method which is appropri- 
ate for his anonymous, (i.e., 
unnamed) objects within a 



new class, and there has to 
be a valid syntax to access 
the method. In this case, the 
data structure address is 
available and only the meth- 
ods need to be obtained. 
The use of IN is to bypass 
the local data structure ad- 
dress inside PT in favor of 
that provided on the stack. 
Syntactically, this has exactly 
the same effect as INHERIT 
but may be used to access 
any object matching the 
hidden data structure. This 



Figure One. Syntax to represent object class. 



CLASS <name> 
DATA 

... \ Data structure and 
\ initialization 
METHODS 

<methodnamel> . . <methodl> 
<methodname2> . . <method2> 
INHERIT 

<ancestor> or NULL 
\ Where NULL means 
\ no ancestor class 
ENDCLASS 



Figure Two. Defining the point class. 



METHODNAME GETX 

METHODNAME PUTX 

METHODNAME GETXY 

METHODNAME SWAPXY 



METHODNAME GETY 
METHODNAME PUTY 
METHODNAME PUTXY 

METHODNAME GRIPE \ Used as failing method 



\ The following are useful general method names providing 

\ for instance initialization and class recognition for the user. 



METHODNAME BUILD 



METHODNAME ASTEXT 



\ The following are hidden methods . 

\ These words will not be visible within the Forth dictionary 
METHOD: GETXYM ( addr — x y ) 
DUP WSIZE + @ SWAP @ 



METHOD: PUTXYM ( x y addr — ) 

DUP >R ! R> WSIZE + ! 

METHOD: SWAPXYM ( addr — ) 

DUP @ OVER WSIZE + @ 

2 PICK ! SWAP WSIZE + ! 



METHOD; 



METHOD ; 



METHOD ; 



CLASS POINT ( x y — ) 
DATA 

, , \ Initialize x y to the values on the stack 
METHODS 

\ Inline functions 
PUTX (x — ) 
GETX ( — x ) 
PUTY ( y — ) 
GETY ( — y ) 
ASTEXT ( — string^ ) 



WSIZE 
WSIZE 
i 

@ ;; 
" Point' 



\ Hidden functions defined earlier 



GETXY ( — x y ) 
PUTXY ( x y — ) 
SWAPXY ( — ) 
BUILD ( x y — ) 
INHERIT 

NULL 
ENDCLASS 



M: GETXYM M; 
M: PUTXYM M; 
M: SWAPXYM M; 
M: PUTXYM M; 



\ An alias for PUTXY here. 
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Figure Three. Using the point class. 



GETXY PT . 
SWAPXY PT Ok 
GETXY PT . . 10 15 ok 
ASTEXT PT COUNT TYPE Point ok 
22 7 BUILD PT ok 
GETXY PT . . 7 22 ok 



15 10 ok \ Note the order printed! 



Figure Four. Defining a rectangle class. 



METHODNAME PUTHEIGHT 
METHODNAME PUTWIDTH 
METHODNAME UPPERLEFT 



METHODNAME GETHEIGHT 
METHODNAME GETWIDTH 
METHODNAME LOWERRIGHT 



METHOD: PUTHEIGHTM ( h addr — ) 

DUP @ ROT + \ The new lower right -> ylr 

SWAP WSIZE 2* + ! 
METHOD; 

METHOD: PUTWIDTHM ( w addr — ) 

DUP WSIZE + @ ROT + \ The new xlr 
SWAP WSIZE 3 * + ! 

METHOD; 

METHOD: GETHEIGHTM ( addr — h ) 

DUP WSIZE 2* + @ SWAP @ - 
METHOD; 

METHOD: GETWIDTHM ( addr — w ) 

DUP WSIZE 3 * + @ SWAP WSIZE + I 
METHOD ; 

CLASS RECTANGLE ( xlr ylr xul yul — ) 
\ Rectangle aligned to the x y axes 



DATA 



\ Upper left 
\ Lower right 



POINT yul xul 
POINT ylr xlr 



METHODS 

PUTWIDTH ( w — ) 
GETWIDTH ( — w ) 
PUTHEIGHT ( h — ) 
GETHEIGHT ( — h ) 
UPPERLEFT ( — x y ) 
LOWERRIGHT ( — x y ) 
ASTEXT ( — string" ) 
BUILD ( xlr ylr xul yul — ) 



PUTWIDTHM M; 
GETWIDTHM M; 

PUTHEIGHTM M; 
GETHEIGHTM M; 
GETXY IN PT ; ; 
WSIZE 2* + GETXY IN PT ; ; 
" Rectangle" ; ; 

DUP >R PUTXY IN PT 

R> WSIZE 2* + 

PUTXY IN PT ; ; 



INHERIT 

PT \ NOTE: Instance of POINT needed, not the class. 
ENDCLASS 



Forth Dimensions 



35 



may only be used within a 
class definition, as it is only 
within the class definition 
that there is knowledge of the 
internal data structures to 
albw theprogrammer access. 

Now for the SQUARE class, 
defined in Figure Five. Pro- 
ducing a new square : 
5 12 13 SQUARE FRED 

We now have a single 
inheritance chain of classes 
to experiment with! [See Fig- 
ure Six.] 

Creating the 
Object Syntax 

The use of defining and 
compiling words in Forth 
provides the programmer 
with the ability to produce 
new language constructs, and 
is the core of the syntax- 
generation process. 

To generate the syntax, 
some preliminary functions 
will prove useful later. Dur- 
ing creation of a specific 
syntax, these will be speci- 
fied as the need arises; but 
here we will separate them 
from the detailed discussion 
of the syntax itself. 

To generate distinct 
method names, it is only a 
matter of making a func- 
tional equivalent to a vari- 
able without using the stor- 
age. In many systems where 
the dictionary and vocabu- 
lary coexist, simple name 
creation would be enough; 
but to be completely gen- 
eral, we will define them as 
follows. 

: METHODNAME 
CREATE , 

To hide the more com- 
plex methods from the nor- 
mal programming environ- 
ment, we can set up a new 
vocabulary into which all of 
these definitions can be 
placed. 

VOCABULARY (METHODS) 

If we wished to interac- 
tively open this vocabulary 
for the storage of a new 
definition and then return to 
the normal FORTH vocabu- 
lary, we would enter the 
sequence: 
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Figure Five. Defining a square class. 



(METHODS) DEFINITIONS 
: ...content of new word..; 
FORTH DEFINITIONS 

This simple sequence may 
be directly converted to 
compiler words as follows. 

: METHOD: 

[COMPILE] (METHODS) 
[COMPILE] DEFINITIONS 
[COMPILE] : 

; IMMEDIATE 

: METHOD; 

[COMPILE] ; 

[COMPILE] FORTH 
[COMPILE] DEFINITIONS 
; IMMEDIATE 

where each immediate word 
used for the interactive se- 
quence is effectively deferred 
by the use of [COMPILE] 
until the execution of 
METHOD: and METHOD;. 
Normal colon definitions may 
be deferred by using COM- 
PILE. 

NULL is a word to indi- 
cate that a search through 
the inheritance chain has 
been unsuccessful, and 
should simply return a mes- 
sage to this effect and stop 
execution. 

: NULL ( flag — ) 
ABORT" 

No method available " 

t 

The structure of defining 
words in Forth provides the 
basis for combining data and 
execution functions within 
one object. The basic form 
for a defining word is: 

: <object> 
CREATE 

... storage set up ... 
DOES> 

... run-time operations 

To match our object syn- 
tax to the appropriate Forth 
structure, the programmer 
builds a definition — based 
on the core words of the 
language — which will do 
what is needed, as in Figure 
Seven. 

This may be demon- 
strated by expanding on the 
POINT example. To provide 
the facility for anonymous 
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METHOD: SIDEM ( s addr — ) \ Store in both height and width 

2DUP PUTHEIGHT IN RECT PUTWIDTH IN RECT 
METHOD; 



CLASS SQUARE ( side x y — ) 
\ A square is a rectangle wit 
DATA 

2DUP , , \ Upper 

2 PICK + , + , \ 

\ Using 

METHODS 

PUTWIDTH ( w — ) 
PUTHEIGHT ( h — ) 
ASTEXT ( — string* ) 
BUILD ( side x y — ) 

INHERIT 

RECT 
ENDCLASS 



1 height = width 
left 

Lower right 

same data structure as before 

M: SIDEM M; 
M: SIDEM M; 

: : " Square" ; ; 

: : DUP >R PUTXY IN PT 
R> SIDEM ;; 



Figure Six. Playing with classes. 




ASTEXT FRED COUNT TYPE Square ok 


GRIPE FRED "FRED" No method available ok 


GETX FRED . 12 OK 




LOWERRIGHT FRED . . 18 


17 ok 


6 9 10 BUILD FRED ok 




UPPERLEFT FRED . . 10 


9 ok 


GETWIDTH FRED . 6 





Figure Seven. An object as a Forth defining word. 

: <object> 
CREATE 

( build the instance data structure ) 
DOES> 
CASE 

methodl OF do.methodl ENDOF 
method2 OF do.method2 ENDOF 

inheritance 
ENDCASE 



access, we need the addi- 
tional concept: a method 
having a true value indi- 
cates that its execution has 
been entered through inher- 
itance or deferral, and that 
only its methods are required, 
not the data structure. [See 
Figure Eight.] 

The process of configur- 
ing our object-oriented syn- 
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tax is simply matching the 
two forms and defining the 
necessary compiling words 
to handle the operations. [See 
Figure Nine.] 

The above constructs take 
less than one page of code, 
yet provide all the function- 
ality discussed at the begin- 
ning of this document. 



Extending the Example: 
Text Window on a PC 

We have developed our 
syntax and object creation 
methods, through an ex- 
ample sequence, from a Point 
to a Rectangle to a Square. A 
text window is an example 
of a rectangle with additional 
attributes: 



Figure Eight. Dropping data address during method inheritance. 



: POINT 
CREATE 



( x y — ) 



DOES>( method dataaddr | method dataaddr true dataaddr2 — ) 
\ Check if execution is entered through inheritance process 
\ and drop the address provided by DOES> if it is. 
OVER TRUE = IF 2 DROP THEN SWAP 
CASE 

GETY OF @ ENDOF \ etc. 

SWAPXY OF (METHODS) SWAPXYM FORTH ENDOF 
\ Switch vocabularies to find the right word 
SWAP TRUE NULL TRUE 

\ Deal with inheritance and stack requirements of ENDCASE 
ENDCASE 



Figure Nine. Defining the required compiling words. 



CLASS [COMPILE] : ; IMMEDIATE 

DATA COMPILE CREATE ; IMMEDIATE 



METHODS 
COMPILE DOES> 
COMPILE = 
[COMPILE] THEN 
IMMEDIATE 



COMPILE OVER 
[COMPILE] IF 
COMPILE SWAP 



COMPILE TRUE 
COMPILE 2DROP 
[COMPILE] CASE 



\ The following two are really deferred aliases 
: : : [COMPILE] OF ; IMMEDIATE 

: ;; [COMPILE] ENDOF ; IMMEDIATE 



M: 

; IMMEDIATE 
M; 

; IMMEDIATE 



[COMPILE] OF 



[COMPILE] FORTH 



[COMPILE] (METHODS) 



[COMPILE] ENDOF 



\ IN is required to access an anonymous object within a new class 
\ which, in practice, operates exactly the same as inheritance. 
IN COMPILE SWAP COMPILE TRUE ; IMMEDIATE 

INHERIT COMPILE SWAP COMPILE TRUE ; IMMEDIATE 

ENDCLASS 

COMPILE TRUE [COMPILE] ENDCASE [COMPILE] ; 

IMMEDIATE 



1. The rectangle may be dis- 

played 

2. The contents may be 
cleared. 

3. Text may be placed any- 
where within the window. 

4. Current text should be 
scrollable in the window. 

To create such a window, 
we would expect to have to 

Forth Dimensions 



use the operating system 
commands of the IBM-PC, 
but these commands should 
not be visible to the user of 
the window. All such de- 
tailed operations should be 
confined to the hidden vo- 
cabulary. The user should 
expect to see a text window 
object characterized by the 
code in Figure Ten. 



The user will still be able 
to apply any methods asso- 
ciated with a rectangle object 
to the text window, as well 
as the new methods specific 
to the text window itself. The 
following code is derived 
from the UR-FORTH access 
to IBM-PC internals, and 
demonstrates what is needed 
to create the new facilities for 



our object, and also the abil- 
ity to keep such details from 
the normal programmer. 

Most of the code in Fig- 
ure Eleven is derived from a 
demonstration example by 
Ray Duncan of LMI, but takes 
advantage of our predefined 
objects by building on the 
POINT facilities. 

We may now complete 
our definition of a text win- 
dow object (see Figure 
Twelve, page 40). 

Efficiency & Generality 

The approach we have 
used above to create an ob- 
ject-oriented syntax leads to 
a direct implementation of 
the requirements, but does 
not lead to fast execution. By 
eliminating the use of in-line 
definitions and by complet- 
ing all definitions within the 
hidden vocabulary, it is 
possible to use vectored ex- 
ecution techniques for 
method access, which re- 
sults in very fast chaining 
through the inheritance list. 

The remaining limitation 
of this implementation is that 
it only supports single in- 
heritance, by which we mean 
that there is a path of inher- 
itance from any particular 
class to a class which inherits 
NULL, and failure to find the 
method within this search 
halts the process. A more 
general solution would be to 
have multiple inheritance for 
a class and allow the search 
to try to find the requested 
method by searching through 
a specified set of class chains 
until it finds the appropriate 
method. From the user's 
syntax requirements, this can 
be accomplished by simply 
introducing a list of inherit- 
ances to replace the single 
instance discussed above. 
From an implementation 
viewpoint, this is not such a 
simple task — but a very good 
analysis-and-programming 
exercise. 
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(GEnie from page 32.) 

not endorse, and never have 
endorsed, the approach that 
has been taken in this area 
by the ANSI team. I felt that, 
in this case, an attempt was 
made, pro forma, to consult 
me. I thank Mitch Bradley for 
at least making an effort to 
hear different opinions be- 
fore taking . . . action. 

From: Greg Bailey 

In reply to John Wavrik's 
recent postings regarding the 
discussion that has followed 
his "disenfranchised" post- 
ing: 

First, I should like to 
apologize to Dr. Wavrik for 
having misunderstood his 
intentions in re-posting his 
architecture article. It was 
dated 19 Aug., appeared on 
GEnie 20 Aug. , and, given its 
wording ("this may be the 
best general response"), it 
seemed to me that this was 
the totality of his response. 
Since a more specific re- 
sponse appeared on GEnie 
five days later, I clearly mis- 
understood his intent 

Second, I should like to 
apologize to Dr. Wavrik if I 
have put any words into his 
mouth. On the other hand, it 
is difficult to discuss the po- 
sitions taken by another 
without restating them 
somewhere along the line; 
and since obviously such 
restatements are not in the 
other party's words, it would 
seem that the same could be 
said of any rebuttal delivered 
by anyone. However, if my 
restatement of what John 
appears to be saying is grossly 
at conflict with his meaning, 
I am glad to be shown what 
the meaning really is. In fair- 
ness, however, one major 
reason for replying to John's 
postings is that he is articu- 
late and seems to me to have 
put many words into the 
mouths of the TC. 

For example, John has 
drawn the following errone- 
ous interpretations of just 
several recently made points: 

"GB's. . . comments illus- 
trate the fact that there are 
also people in the Forth 



Figure Ten. User-level view of window code. 



METHODNAME CLEAR METHODNAME DISPLAY 

METHODNAME SCROLLUP METHODNAME SCROLLDOWN 

METHODNAME >XY 



CLASS WINDOW ( xlr ylr xul yul — ) 
DATA 

, , , , \ Rectangle 
\ Plus additional attributes internal to window operations 
METHODS 



CLEAR 


M: 


... M; 


DRAW 


M: 


... M; 


SCROLLUP 


M: 


... M; 


SCROLLDOWN 


M: 


... M; 


>XY ( x y — 


) \ 


Move c 



3or to x y 
\ within the window 
M: ... M; 
ASTEXT M: . . . M; 

BUILD M: . . . M; 

INHERIT 

RECT 
ENDCLASS 



Figure Eleven. Details derived from LMI demo. 



HEX 

METHOD: WPAR0 ( addr — dx cx bx ) 

\ Fetch parameters for an IBM-PC video I/O call 

DUP >R LOWERRIGHT IN RECT 100 * + 

\ dx from ul 

R@ UPPERLEFT IN RECT 100 * + 
\ cx from lr 
R> WSIZE 4 * + @ 
\ bx from the attribute variable 
METHOD; 



METHOD: W-ATTRIB ( attrib addr — ) 
\ Change the initializing attribute 

SWAP 100 * SWAP WSIZE 4 * + ! 
METHOD; 



METHOD: W-EXEC ( dx cx bx ax — ) 
\ Execute the window function 

regAX ! regBX ! regCX ! regDX ! 10 INT 8 6 
METHOD; 



METHOD: W-CLEAR \ Initialize the window 

WPAR8 0600 W-EXEC 
METHOD; 

METHOD: W-UP \ Scroll the window up 

WPARg 0601 W-EXEC 
METHOD; 

METHOD: W-DOWN \ Scroll the window down 

WPAR0 0701 W-EXEC 
METHOD ; (Figure continues.) 
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(Figure Eleven, continued.) 



METHOD: W-GOTOXY ( x y addr — ) 
\ Cursor addressing within the window 

UPPERLEFT IN RECT D+ GOTOXY 
METHOD; 

METHOD: W-HOME ( addr — ) 

\ Move cursor to the window home position, upper left 

UPPERLEFT IN RECT GOTOXY 
METHOD; 

METHOD: W-LLC ( addr — ) 

\ Move the cursor to the lower left corner of window 

WSIZE + DUP @ SWAP WSIZE + @ GOTOXY 
METHOD; 

METHOD: W-BORDER ( addr — ) 

\ Draw a border around the window using IBM character set 
DUP >R UPPERLEFT IN RECT R> LOWERRIGHT IN RECT 
\ The window parameters are now on the stack 
OVER 1+ 4 PICK 
DO \ Do two sides 

I 3 PICK 1- GOTOXY 0C4 EMIT 

I OVER 1+ GOTOXY 0C4 EMIT 



LOOP 
DUP 



1+ 



PICK 



DO \ Do the other sides 



OVER 1+ 
3 PICK 



I GOTOXY 0B3 
1- I GOTOXY 



EMIT 
0B3 



EMIT 



LOOP 

OVER 1+ 
3 PICK 
1+ SWAP 
1- SWAP 

METHOD; 

DECIMAL 



PICK 1- GOTOXY OBF EMIT 

OVER 1+ GOTOXY 0C0 EMIT 

1+ SWAP GOTOXY 0D9 

1- SWAP GOTOXY ODA 



( 
( 

EMIT 
EMIT 



urc) 
11c ) 
( 
( 



lrc 
ulc 



community for whom re- 
usability of code is not 
important...." "Forth has 
acquired an unfortunate 
reputation as being highly 
non-portable, and GB's 
comments serve to rein- 
force this impression." 
". . .throw away time and 
effort needed just for a 
marginal gain in execu- 
tion speed. ..." "His [GB's] 
work does not require 
portability..." "No stan- 
dard is needed for people 
who plan to ignore it any- 
how..." "...ER and GB's 
responses add unfortu- 
nate confirmation to the 
suspicion that the ANSI 
team is writing a new 
language which they plan 
to pass off as Forth." "The 



ANSI team is dominated 
by people who do not 
place much value on 
portability — and Greg 
Bailey says as much." 

These and many similar 
passages from recent 
postings of John's serve to 
create, by repetition, the er- 
roneous impression that 
members of the TC, includ- 
ing myself, have little or no 
interest in portability or reus- 
ability of code and are doing 
grievous harm to what John 
sees as Forth. In fact, this is 
an erroneous interpretation 
of at least my position, and I 
presume that the root of the 
problem is that at least until 
the semantic issue I men- 
tioned on 16 August is clari- 
fied, John will continue to 



misunderstand the motives 
and actions of the TC. 

Simply stated, again, my 
understanding of John 
Wavrik's position is that to 
him Forth means (and I pre- 
sume he believes it was in- 
tended to mean) a static, 
open implementation model. 
For example, he considers 
that Forth includes a word 
spelled DOCOL that, when 
executed, returns a value that 
can be passed to , (comma) 
with specific and well-de- 
fined meaning having to do 
with the creation of a body of 
executable code. He also 
believes that Forth includes 
words spelled ? BRANCH and 
OBRANCH that are, and I 
gather must be, used in 
implementing control-flow 



words. He feels likewise 
about the existence, and 
likewise about a method of 
implementation that should 
be guaranteed to work, for 
LIT. John, am I misstating 
your position here at all? I 
don't think I misunderstand 
you. What I have heard you 
say before is that you don't 
really care what it is, but 
whatever it turns out to be 
you want it all (i.e., you 
really strongly desire a stan- 
dard that prescribes an 
implementation — whether 
you draw the "architectural" 
boundary there or not — at 
least completely enough that 
you know and can manipu- 
late the executable text of a 
colon definition; that you 
know and can manipulate 
the structure of the dictio- 
nary; and so on). My under- 
standing of your position is 
that a laudable standard could 
be formed by taking virtually 
anygood implementation of 
Forth, documenting the 
whole thing, and saying that 
standard Forth must be 
implemented in this way on 
all computers. 

Before I reply in detail to 
your postings, I think it would 
be useful to refine with you 
the above paragraph as 
needed, so that what we 
have is a concise but accu- 
rate statement of where you 
draw the line. 

At the same time, so that 
we can all calibrate your sen- 
sitivity to the performance 
one may expect of an ap- 
plication written in Forth, I 
would like to know what 
you mean by "marginal gains 
in speed." For example, is a 
lOx performance improve- 
ment on a given CPU mar- 
ginal to you? Readers of these 
postings might erroneously 
conceive, for example, that 
the architecture-independent 
definition of Forth we have 
tried to write in the dpANS 
was undertaken for no other 
reason than to permit imple- 
mentations that shave a few 
percent off execution speed. 
Nothing could be farther from 
the truth. 
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Figure Twelve. Completed definition of text window object. 



HEX 

CLASS WINDOW ( xlr ylr xul yul — ) 
DATA 

, , \ ul POINT 

, , \ lr POINT or RECTANGLE 

700 , \ Additional attribute internal to window operations 
METHODS 



CLEAR 


M: 


DUP 


W-CLEAR 


W-HOME M; 


DRAW 


M: 


DUP 


W-BORDER 


DUP W-CLEAR W-HOME M; 


SCROLLUP 


M: 


DUP 


W-UP W- 


-LLC M; 


SCROLLDOWN 


M: 


DUP 


W-DOWN 


W-HOME M; 



>XY ( x y — ) \ Move cursor to position x y in window 

M: W-GOTOXY M; 
ATTRIBUTE ( attr — ) \ Change window attribute value 

M: W-ATTRIB M; 
ASTEXT : : " Text Window" ; ; 

BUILD ( xlr ylr xul yul — ) 

: : DUP >R BUILD IN RECT 

\ Reuse the previous definition 

700 R> WSIZE 4 * + ! ;; \ Add default attribute 

INHERIT 

RECT 
ENDCLASS 
DECIMAL 

The following demonstrates use of the text window objects: 

30 10 5 5 WINDOW Wl 

7 15 40 7 WINDOW W2 
70 23 10 21 WINDOW W3 

: WDEMO 

CLS DRAW Wl DRAW W2 DRAW W3 

\ Window W3 now active for text entry. 

. " We will scroll the left window up" 

1 >XY W3 ." and the right window down." 

BEGIN 1+ 

SCROLLUP Wl ." Line # " DUP . 

SCROLLDOWN W2 ." Line # " DUP 
? TERMINAL UNTIL DROP 

CLEAR W3 ." The demonstration is finished." 
GOTOXY 



I still feel that we are 
debating semantics and 
would like, if possible, to 
partition the argument into 
two issues: (1) the merits of 
architecture independence 
vs. prescribed implementa- 
tion methods, and (2) spe- 
cific things you would like to 
do in a portable way but feel 
it is impossible to do in terms 
of the dpANS. If possible, it 
would also help if items in 
this latter category were 
identified as to their portable 
feasibility in terms of Forth- 
79 or Forth-83. 

As a final point for this 
posting, my several anec- 
dotes about Chuck Moore 
were not intended to de- 
value portability orreusability 
of code. I was instead tossing 
them out because it seemed 
to me that John considered it 
self-evident that Forth was 
conceived to be what he 
wants it to be . This struck me 
as curious since, for as long 
as I have been participating 
(since the end of 1975), the 
inventor of Forth and those 
who have worked with him 
have continually been de- 
veloping its architecture to 
increase the breadth of its 
applicability. Obviously, this 
development could have 
been arrested at any point to 
produce a frozen model that 
I believe would have the 
properties John seeks. This 
does not mean that our ap- 
plications lack practical 
portability or reusability. It 
does, however, mean that, 
to the extent that those appli- 
cations exploited the pro- 
cessor or the characteristics 
of the implementation, they 
would need attention when 
dusted off. 

From: Greg Bailey 

John Wavrik writes on 25 
Aug. 91 that Mitch's account 
of events with user-defined 
control structures failed to 
mention that John does not 
endorse, nor has he ever 
endorsed, the approach that 
has been taken in this area 
by the ANSI team. 

It would be enlightening 
for John to amplify on this 
January 1992 February 



negative opinion by stating 
his reasons. It would also be 
useful if John were to illus- 
trate these reasons with some 
examples of things that can't 
be done portably in terms of 
the operators included in the 
dpANS. 

Useful things that can't be 
done are valid demonstra- 
tions of weakness in the 
standard, and will always be 
interesting to the TC. How- 
ever, the general methods 
documented in the dpANS 



(specifically of postponing 
members of the basic con- 
trol-flow wordset) were cho- 
sen because they do work on 
the majority of systems; in- 
deed, the major differences 
between these systems had 
to do with manipulation of 
items on the compile-time 
control-flow stack, and these 
differences have been ad- 
dressed with operators to 
manipulate them. Con- 
versely, "just using ? BRANCH 
and BRANCH" will nofwork 



on many systems, because 
many systems lack these 
words. Indeed, some, such 
as the Novix and Harris chips, 
and microcoded or native 
code implementations, have 
no place for those words. On 
the other hand, [COMPILE] 
IF or POSTPONE IF does in 
fact cover the bases in such 
cases. 

The TC believes that the 
ability of a Forth program- 
mer to compose control 

(Continues on page 42.) 
Forth Dimensions 



HARVARD SOFTWORKS 

NUMBER ONE IN FORTH INNOVATION 

(513) 748-0390 P.O. Box 69, Springboro, OH 45066 



MEET THAT DEADLINE ! ! ! 

• Use subroutine libraries written for 
other languages! More efficiently! 

• Combine raw power of extensible 
languages with convenience of 
carefully implemented functions! 

• Yes, it is faster than optimized C! 

• Compile 40,000 lines per minute! 

• Stay totally interactive, even while 
compiling! 

• Program at any level of abstraction 
from machine code thru application 
specific language with equal ease 
and efficiency! 

• Alter routines without recompiling! 

• Use source code for 2500 functions! 

• Use data structures, control 
structures, and interface protocols 
from any other language! 

• Implement borrowed feature, often 
more efficiently than in the source! 

• Use an architecture that supports 
small programs or full megabyte 
ones with a single version! 

• Forget chaotic syntax requirements! 

• Outperform good programmers 
stuck using conventional languages! 
(But only until they also switch.) 

HS/FORTH with FOOPS - The only 
full multiple inheritance 
interactive object oriented 
language under MSDOS! 

Seeing is believing, OOL's really are 
incredible at simplifying important 
parts of any significant program. So 
naturally the theoreticians drive the 
idea into the ground trying to bend all 
tasks to their noble mold. Add on 
OOL's provide a better solution, but 
only Forth allows the add on to blend 
in as an integral part of the language 
and only HS/FORTH provides true 
multiple inheritance & membership. 

Lets define classes BODY, ARM, and 
ROBOT, with methods MOVE and 
RAISE. The ROBOT class inherits: 

INHERITS BODY 

HAS> ARM RightArm 

HAS> ARM LeftArm 
If Simon, Alvin, and Theodore are 
robots we could control them with: 
Alvin 's RightArm RAISE or: 
+5 -10 Simon MOVE or: 
+5 +20 FOR-ALL ROBOT MOVE 

The painful OOL learning curve 
disappears when you don't have to 
force the world into a hierarchy. 
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WAKE UP ! ! ! 

Forth is no longer a language that 
tempts programmers with "great 
expectations", then frustrates them 
with the need to reinvent simple tools 
expected in any commercial language. 

HS/FORTH Meets Your Needs! 

Don't judge Forth by public domain 
products or ones from vendors 
primarily interested in consulting - 
they profit from not providing needed 
tools! Public domain versions are 
cheap - if your time is worthless. 
Useful in learning Forth's basics, they 
fail to show its true potential. Not to 
mention being s-l-o-w. 

We don't shortchange you with 
promises. We provide implemented 
functions to help you complete your 
application quickly. And we ask you 
not to shortchange us by trying to 
save a few bucks using inadequate 
public domain or pirate versions. We 
worked hard coming up with the ideas 
that you now see sprouting up in other 
Forths. We won't throw in the towel, 
but the drain on resources delays the 
introduction of even better tools. Don't 
kid yourself, you are not just another 
drop in the bucket, your personal 
decision really does matter. In return, 
well provide you with the best tools 
money can buy. 

The only limit with Forth is your 
own imagination! 

You can't add extensibility to fossilized 
compilers. You are at the mercy of 
that language's vendor. You can easily 
add features from other languages to 
HS/FORTH. And using our automatic 
optimizer or learning a very little bit 
of assembly language makes your 
addition zip along as well as in the 
parent language. 

Speaking of assembly language, 
learning it in a supportive Forth 
environment turns the learning curve 
into a light speed escalator. People 
who failed previous attempts to use 
assembly language, conquer it in a few 
hours or days using HS/FORTH. 

WINTER SALE »> 
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HS/FORTH runs under MSDOS or 
PCDOS, or from ROM. Each level includes 
all features of lower ones. Level upgrades: 
$25. plus price difference between levels. 
Source code is in ordinary ASCII text files. 

HS/FORTH supports megabyte and larger 
programs & data, and runs as fast as 64k 
limited Forths, even without automatic 
optimization — which accelerates to near 
assembler language speed. Optimizer, 
assembler, and tools can load transiently. 
Resize segments, redefine words, eliminate 
headers without recompiling. Compile 79 
and 83 Standard plus F83 programs. 

PERSONAL LEVEL $299. 
NEW! Fast direct to video memory text 
& scaled/clipped/windowed graphics in bit 
blit windows, mono, cga, ega, vga, all 
ellipsoids, splines, bezier curves, arcs, 
turtles; lightning fast pattern drawing even 
with irregular boundaries; powerful 
parsing, formatting, file and device I/O; 
DOS shells; interrupt handlers; 
call high level Forth from interrupts; 
single step trace, decompiler, music; 
compile 40,000 lines per minute, stacks; 
file search paths; format to strings, 
software floating point, trig, transcen- 
dental, 18 digit integer & scaled integer 
math; vars: A B * IS C compiles to 4 words, 
1..4 dimension var arrays; automatic 
optimizer for machine code speed. 

PROFESSIONAL LEVEL $399. 

hardware floating point - data structures 
for all data types from simple thru 
complex 4D var arrays - operations 
complete thru complex hyperbolics; 
turnkey, seal; interactive dynamic linker 
for foreign subroutine libraries; round 
robin & interrupt driven multitaskers; 
dynamic string manager; file blocks, 
sector mapped blocks; x86&7 assemblers. 

PRODUCTION LEVEL $499. 
Metacompiler: DOS/ROM/direct/indirect; 
threaded systems start at 200 bytes, 
Forth cores from 2 kbytes; 
C data structures & struct* compiler, 
Turbo Window-C MetaGraphics library, 
200 graphic/window functions, PostScript 
style line attributes & fonts, viewports. 

ONLINE GLOSSARY $ 45. 

PROFESSIONAL and PRODUCTION 
LEVEL EXTENSIONS: 

FOOPS+ with multiple inheritance $ 79. 
TOOLS & TOYS DISK $ 79. 

286FORTH or 386FORTH $299. 

16 Megabyte physical address space or 
gigabyte virtual for programs and data; 
DOS & BIOS fully and freely available; 
32 bit address/operand range with 386. 
ROMULUS HS/FORTH from ROM $ 99. 

Shipping/system: US: $7. Canada: $19. 
foreign: $49. We accept MC, VISA, & AmEx 

Free Online Glossary plus Tools & Toys 
Disk with all systems. 
Free 286FORTH (also for 386) with all 
Professional and Production level systems. 
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NGS FORTH 

A FAST FORTH, 
OPTIMIZED FOR THE IBM 
PERSONAL COMPUTER AND 
MS-DOS COMPATIBLES. 



STANDARD FEATURES 
INCLUDE: 



•79 STANDARD 

•DIRECT I/O ACCESS 

•FULL ACCESS TO MS-DOS 
FILES AND FUNCTIONS 

•ENVIRONMENT SAVE 
& LOAD 

•MULTI -SEGMENTED FOR 
LARGE APPLICATIONS 

•EXTENDED ADDRESSING 

•MEMORY ALLOCATION 
CONFIGURABLE ON-LINE 

•AUTO LOAD SCREEN BOOT 

•LINE & SCREEN EDITORS 

•DECOMPILER AND 

DEBUGGING AIDS 

•8088 ASSEMBLER 
•GRAPHICS & SOUND 
•NGS ENHANCEMENTS 
•DETAILED MANUAL 
•INEXPENSIVE UPGRADES 
•NGS USER NEWSLETTER 

A COMPLETE FORTH 
DEVELOPMENT SYSTEM. 



PRICES START AT $70 



NEW<*-HP-150 6 HP- 110 
VERSIONS AVAILABLE 

NEXT GENERATION SYSTEMS 
P.O.BOX 2987 
SANTA CLARA/ CA. 95055 
(408) 241-5909 
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C GEnie, Jrom page 40) 

structures in terms of the dpANS is vastly 
superior to that provided by either Forth- 
79 or Forth-83. Please note that the 
xB RANCH words were not required and, 
indeed, were not particularly encour- 
aged, nor were they anywhere near 
universally supported; and that there 
was no practically portable way for 
users to implement control structures 
without depending on intimate knowl- 
edge of the intermediate database used 
by each system. Anyone with evidence 
to contradict this belief is encouraged to 
demonstrate problems during the re- 
view period. 

From: Elizabeth Rather 

To: John Wavrik 

Re: Traditional Forth" 

Thank you for your very clear dis- 
course defining what you mean by that 
term. I would like to urge you, however, 
to try to find a better adjective than 
"traditional, " because that implies a heri- 
tage, ancestry, and universality that re- 
ally isn't justified. For example, the 
xBRANCH words you mention were in- 
troduced in Forth-83 as an experimental 
wordset (by Kim Harris, I believe), and 
systems that maintained an allegiance to 
Forth-79 would not have used them. So 
you might say that "some'' or even 
"many" implementations work that way, 
but prior to Forth-83, nosystems worked 
that way that I am aware of; and it was 
not, by any means, universally adopted 
afterwards. You may feel that this is 
unnecessary quibbling over an adjec- 
tive, but it is an adjective that has value 
judgements associated with it, too, and 
inappropriate use of it introduces heat 
into what should be a logical discussion. 

Along the same lines, use of "as- 
sembling" to describe laying down 
material for the Forth engine to process 
obfuscates more than it enlightens, be- 
cause it directs the reader's thoughts to 
machine code. That was what I was 
"hogwash-ing" at. 

Now, IH leave it to Mitch to tell you 
how to write portable literals in ANS 
Forth, because he does that sort of thing 
so well, and concentrate on the principles. 

The TC considered including the 
xBRANCH words, but left them out be- 
cause those of us who were familiar with 
a lot of systems (Martin Tracy, in par- 
ticular) were able to show that, in fact, 
they had not been implemented widely, 
for some pretty good technical reasons. 
Instead, we provided POSTPONE and 
liberalized the use of structure words, 
and finally introduced some lower-level 
words (SO, STILL, etc) in the TOOLKIT 
wordset. Wil Baden was the principal 
42 



architect of our approach to handling 
this, and although we've fine-tuned his 
work somewhat, we think he did a great 
job. The result is that you have a great 
deal more power and flexibility by 
using phrases such as POSTPONE ELSE 
(for an unconditional forward branch) 
than with the other words, because it is 
required and simple to implement, 
whereas the BRANCH tools were in vio- 
lation of so many implementations that 
there is no general expectation that it 
can be there. 

In fact, a number of us on the TC like 
to use such techniques as you describe, 
and believe that ANS Forth offers greatly 
improved power and flexibility in these 
areas while additionally taking steps to 
improve portability of these techniques 
onto direct-compilation systems, Forth 
chips, and 32-bit systems. I guarantee 
you that your strategies wouldn't have 
worked on any of these! So the net 
result is not only more programmer 
power, but greater portability. 

From: L. Zettel 

Pardon me while I pick a few nits. 
Now that we are agreeing, for the time 
being, that "traditional Forth" is the 
Forth described by Brodie and by Kelly 
& Spies, I thought it would be enlight- 
ening to look up LIT in the indices of 
these books. Very interesting. Kelly & 
Spies (p. 320) give the definition: 

: LITERAL 
STATE @ 

IF COMPILE LIT 

, THEN ; IMMEDIATE 

Brodie, second edition offers 

: LITERAL ( n ) 

COMPILE (LITERAL) 
, ; IMMEDIATE 

Significantly (to my mind), neither 
offers a definition of LIT or (LIT- 
ERAL) . 

From: John Wavrik 

Re: X3J14 Holding Pattern Here 

Elizabeth Rather writes, 

"The disagreement between you and 
the committee is not 'who wants 
portability' but how portability is 
achieved We believe it can most 
usefully be achieved by defining the 
behavior of Forth words, and you'd 
prefer to see their implementation 
standardized." 

Actually, the disagreement hinges 
more on what Forth is capable of 
doing — or how powerful and flexible 
the language should be. 
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This is probably the main 
source of disagreement It 
might stem from a difference 
in view of what the Forth 
language is, has been, or 
could become. It might stem 
from a willingness to trade 
away capabilities of Forth to 
achieve harmony among 
vendors. It might stem from 
a disagreement about what it 
should be possible to do 
portably. 

My claim is that Forth has 
traditionally been a language 
which allows the user to build 
major language features. 
(There is a Forth literature 
discussing variant methods 
for doing local variables, 
exception handling, adding 
object orientation, etc.) Forth 
has been a toolkit for build- 
ing application-oriented lan- 
guages. The ANSI team is 
heading in the direction of 
including some important 
features (local variables, ex- 
ception handling, etc.) but 
removingthe ability to build 
such things. 

There are several other 
points of disagreement — 
most notably those having to 
do with clarity of definitions 
and simplicity of action. 
Words whose meanings can 
be interpreted differently by 
different implementors are 
useless for portable pro- 
gramming. The best tools 
available should be used to 
make the actions clear. Empty 
abstraction should be 
avoided — the actions of 
words should be as simple 
as possible. There are impor- 
tant aspects of the character 
of traditional Forth (simplic- 
ity, access, comprehensibil- 
ity, etc.) that should be pre- 
served. 

There is no disagreement 
at all about describing Forth 
words in terms of their be- 
havior. This is how Forth 
words have always been 
described. (On most systems, 
the lowest-level words have 
always been implemented 
in machine language, so it 
has never been possible to 
standardize their implemen- 
tation.) 
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In this regard, I should 
mention that clarity of a de- 
scription of behavior is im- 
proved immensely if a glos- 
sary entry is accompanied 
by a sample definition. In the 
Golden Days of Forth, this 
was a way we old-timers 
found helpful to convey the 
intended behavior of a word. 
I realize that the young folk 
have extreme prejudices 
against doing sensible things 
like this, so I'll just keep my 
mouth shut and rock on the 
porch here, looking through 
my old copies of BYTE 
magazine and generally 
basking in nostalgia! 

"Can't offhand think of 
any languages that de- 
scribe how their data 
structures are arranged in 
memory, let along how 
their code is arranged in 
memory, which is what 
you seem to expect of 
Forth. ANS Forth pays a 
great deal of attention to 
describing data types, at 
least as clearly as C, etc. It 
also explicitly describes 
(Section 5.4 in BASIS, 3.4 
in dpANS-2) the regions 
of memory that are ad- 
dressable by a standard 
program. Most high-level 
languages don't let you 
address memory at all. C 
sort of does, via 'point- 
ers,' but pointers are still a 
lot more abstract than 
Forth's addresses." 

Conventional languages 
allow data structures only to 
be created by a limited set of 
mechanisms built into the 
language — and then impose 
further limitations on the sta- 
tus of these structures (how 
they can be passed to func- 
tions, how operators may act 
on them, etc.). This is one of 
the reasons for using Forth. 

Obviously, someone 
must decide how a data 
structure is arranged in 
memory, how it is accessed, 
etc. In conventional lan- 
guages, it is the designer of 
the language. In Forth, it can 
be the user (who is, in a real 
sense, the designer of lan- 



guages). 

I really have never under- 
stood arguments which pick 
some limitations that make 
other languages inflexible 
and use that to suggest that 
Forth should be equally in- 
flexible. 

From: John Wavrik 
Subject: Nostalgia???!!??? 

Elizabeth Rather writes, 
"Our discussion of devia- 
tions from the earliest days 
to the present is intended 
to point out that there has 
never been such a golden 
age, and that your nostal- 
gia for it is, therefore, in- 
appropriate." 

Somehow, I feel like I am 
in the middle of the novel 
1984, in which the establish- 
ment had newspapers re- 
written to show that certain 
events never happened. Here 
is what I remember: 

When I became involved 
with Forth, most computer 
magazines had regular ar- 
ticles on the language. BYTE 
magazine devoted at least 
one full issue to Forth (per- 
haps more). Some magazines 
had a Forth column. My first 
course on Forth was taught 
(by request) to 30 faculty and 
staff members — including 
representatives from the 



seemed magically to run on 
others — and there was a 
healthy exchange of appli- 
cations and ideas. Magazine 
ads offered a variety of utili- 
ties (good editors, decompil- 
ers, etc.). You didn't have to 
justify your choice of Forth. 

I am really trying to be a 
good citizen — so I am trying 
to believe with all my might 
that this never happened (but 
if it didn't, then why do I 
have on the wall of my office 
a poster of the BYTE maga- 
zine cover featuring Forth?). 

We are losing sight of the 
purpose of introducing this. 
The way Forth is described 
in the most popular texts 
was quite common — which 
is why the texts described it 
as they did. One must re- 
member that, if one is writ- 
ing a general textbook for a 
language (rather than a 
manual for a particular dia- 
lect), it is best to stick to 
common practice. I have 
chosen the name Traditional 
Forth for this language be- 
cause it is the form in which 
Forth was realized in a great 
many systems, from the ear- 
liest times to the present 

Please note that there is 
nothing in the previous 
paragraphs that says there 
were no variant systems. 
There is nothing in the previ- 



ANSI is headed toward 
including some important 
features, but removing the 
ability to build such things... 



computer center, who 
wanted to be able to support 
the hot new language. Forth 
was the official language of 
astronomy, and the Center 
for Astrophysics and Space 
Studies (CASS) was one of 
the main groups using it at 
UCSD. Several people at 
Scripps Institute of Ocean- 
ography also used the lan- 
guage. I regularly received 
requests about where to ob- 
tain an implementation of 
the language. Applications 
written for one platform 
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ous paragraphs that casts 
aspersions on the use of a 
non-standard system for cer- 
tain applications. There is 
nothing in the previous 
paragraphs that says that 
everything that has been 
done in the past in an at- 
tempt to standardize Forth 
was done perfectly. 

I don't regard as nostalgia 
an effort to call attention to 
some extremely strong and 
positive things that were 
going on with the Forth lan- 
guage at that time. 

January 1992 February 



Contributions from the Forth Community 



We are beginning to assemble a great collection of Forth code in machine-readable form. 
If you need a good Forth, it is probably here. 



Minimum-requirement Forths: 
The kitchen-sink Forths: 
Complete starters: 
Object-oriented Forths: 
Macintosh Forths: 
IBM Forths: 
Atari Forth: 
8051 Forths: 

Graphic and floating-point Forths: 

Forth tutorials: 

Applications: 



PocketForth, PYGMY, eForth 

F-PC, BBL 

F83, Kforth, ForST 

Yerkes, MOPS 

Yerkes, MOPS, PocketForth 

PYGMY, F-PC, BBL, F83, Kforth, eForth 

ForST 

8051 ROMmable Forth, eForth 
Yerkes, MOPS, F-PC, Kforth 

The Forth Course, F-PC Teach 

Forth List Handler, Forth Spreadsheet, 

Automatic Structure Charts, A Simple Inference Engine, 

The Math Toolbox 



Great demos from St. Petersburg: AstroForth and AstroOKO 

(See the Mail Order Form inside for more complete descriptions) 

Yet to come: 

• Collections of tools and techniques are being assembled that cover communications, hardware 

drivers, data analysis, and more math and numerical recipes. 

Things we need or which are not currently available in machine-readable form: 

• Original listings of fig-Forth for any machine on disk. We do not currently have them. 

• We can use many more applications and application ideas that include source code. 

• Code from the authors of FORML papers and past Forth Dimensions articles. 

Send submissions to: FIG, do Publications Committee, P.O Box 8231, San Jose, CA 95155 



Forth Interest Group 

P.O.Box 8231 

San Jose, CA 95155 
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